Summary:
We currently only collect external-linkage symbols in the collector,
which results in missing some typical symbols (like no-linkage type alias symbols).
This patch relaxes the constraint a bit to allow collecting more symbols.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41759
llvm-svn: 322067
The Ananas Operating System (https://github.com/zhmu/ananas) has shared
library support as of commit 57739c0b6ece56dd4872aedf30264ed4b9412c77.
This change adds the necessary settings to clang so that shared
executables and libraries can be build correctly.
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D41500
llvm-svn: 322064
Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc.
For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions.
Differential Revision: https://reviews.llvm.org/D40478
Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea
llvm-svn: 322063
CET (Control-Flow Enforcement Technology) introduces a new mechanism called IBT (Indirect Branch Tracking).
According to IBT, each Indirect branch should land on dedicated ENDBR instruction (End Branch).
The new pass adds ENDBR instructions for every indirect jmp/call (including jumps using jump tables / switches).
For more information, please see the following:
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
Differential Revision: https://reviews.llvm.org/D40482
Change-Id: Icb754489faf483a95248f96982a4e8b1009eb709
llvm-svn: 322062
When cross-compiling for Windows on Unix, the built toolchain will need
to be transferred to Windows to actually run. My opinion is that the
Unix build should use symlinks, and the transfer to Windows should take
care of making those symlinks usable. E.g., I envision tarballs to be a
common form of transfer from Unix to Windows, in which case the tarball
can be created using --dereference to follow the symlinks.
The motivation here is that, when cross-compiling for Windows on Unix,
the installation will *already* create symlinks. The reason is that the
installation script will be invoked without knowing the host system, so
the `if(UNIX)` check in the installation symlink creation script will
reflect the build system rather than the host system. We could either
make the build and install trees both contain copies or both contain
symlinks, and using symlinks is a significant space saving without (in
my opinion) having any detrimental effect on the usage of the cross-
compiled toolchain on Windows.
A secondary motivation is that Windows 10 version 1703 and later finally
lift the administrator rights requirement for creating symbolic links
(if the system is in Developer Mode), which makes symlinks a lot more
practical even on Windows. Of course Unix and Windows symlinks aren't
interoperable, but symlinks for Windows toolchains is a reasonable
future direction to be going in anyway.
Differential Revision: https://reviews.llvm.org/D41314
llvm-svn: 322061
The code that checks the immediate wasn't masking to the lower 3-bits like the code in X86InstrInfo.cpp that's used by the peephole pass does.
llvm-svn: 322060
SCEV tracks the correspondence of created SCEV to original instruction.
However during creation of SCEV it is possible that nuw/nsw/exact flags are
lost.
As a result during expansion of the SCEV the instruction with nuw/nsw/exact
will be used where it was expected and we produce poison incorreclty.
Reviewers: sanjoy, mkazantsev, sebpop, jbhateja
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41578
llvm-svn: 322058
Summary:
All other templated methods have explicit instantiations but this one is
missing. Discovered while building with a clang with inliner
modifications.
Reviewers: espindola
Subscribers: emaste, llvm-commits, davidxl
Differential Revision: https://reviews.llvm.org/D41847
llvm-svn: 322057
If the offset is differ in two addressing mode we can continue only if
ScaleReg is not set due to we will use it as merge of different offsets.
It should fix PR35799 and PR35805.
Reviewers: john.brawn, reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41227
llvm-svn: 322056
The CTRLoop pass performs checks on the argument of certain libcalls/intrinsics,
and assumes the arguments must be of a simple type. This isn't always the case
though. For example if we unroll and vectorize a loop we may end up with vectors
larger then the largest legal type, along with intrinsics that operate on those
wider types. This happened in the ffmpeg build, where we unrolled a loop and
ended up with a sqrt intrinsic that operated on V16f64, triggering an assertion.
Differential Revision: https://reviews.llvm.org/D41758
llvm-svn: 322055
r322028 attempted to remove something from the "Manglings"
list when it was no longer valid, and did so with 'erase'.
However, StringRefs to these were stored, so these became
dangling references. This patch changes to using 'remove' instead
of 'erase' to keep the strings valid.
llvm-svn: 322052
I had to drop fast-isel-abort from a test because we can't fast isel some of the mask stuff. When we used intrinsics we implicitly fell back to SelectionDAG for the intrinsic call without triggering the abort error. But with native IR that doesn't happen the same way.
llvm-svn: 322050
The pattern was this
def : Pat<(i32 (zext (i8 (bitconvert (v8i1 VK8:$src))))),
(MOVZX32rr8 (EXTRACT_SUBREG (i32 (COPY_TO_REGCLASS VK8:$src, GR32)), sub_8bit))>, Requires<[NoDQI]>;
but if you just let (i32 (zext X)) match byte itself you'll get MOVZX32rr8. And if you let (i8 (bitconvert (v8i1 VK8:$src))) match by itself you'll get (EXTRACT_SUBREG (i32 (COPY_TO_REGCLASS VK8:$src, GR32)), sub_8bit).
So we can just let isel do the two patterns naturally.
llvm-svn: 322049
This commit does two things. Firstly, it adds a collection of flags which can
be passed along to the target to encode information about the MBB that an
instruction lives in to the outliner.
Second, it adds some of those flags to the AArch64 outliner in order to add
more stack instructions to the list of legal instructions that are handled
by the outliner. The two flags added check if
- There are calls in the MachineBasicBlock containing the instruction
- The link register is available in the entire block
If the link register is available and there are no calls, then a stack
instruction can always be outlined without fixups, regardless of what it is,
since in this case, the outliner will never modify the stack to create a
call or outlined frame.
The motivation for doing this was checking which instructions are most often
missed by the outliner. Instructions like, say
%sp<def> = ADDXri %sp, 32, 0; flags: FrameDestroy
are very common, but cannot be outlined in the case that the outliner might
modify the stack. This commit allows us to outline instructions like this.
llvm-svn: 322048
This splits relocation processing in two steps.
First, analyze what needs to be done at the relocation spot. This can
be a constant (non preemptible symbol, relative got reference, etc) or
require a dynamic relocation. At this step we also consider creating
copy relocations.
Once that is done we decide if we need a got or a plt entry.
The code is simpler IMHO. For example:
- There is a single call to isPicRel since the logic is not split
among adjustExpr and the caller.
- R_MIPS_GOTREL is simple to handle now.
- The tracking of what is preemptible or not is much simpler now.
This also fixes a regression with symbols being both in a got and copy
relocated. They had regressed in r268668 and r268149.
The other test changes are because of error messages changes or the
order of two relocations in the output.
llvm-svn: 322047
When cross-compiling, we cannot use the just built toolchain, instead
we need to use the host toolchain which we assume has a support for
targeting the selected target platform. We also need to pass the path
to the native version of llvm-config to external projects.
Differential Revision: https://reviews.llvm.org/D41678
llvm-svn: 322046
The addresses of undefined symbols that make it into the final
executable (i.e. weak references to non-existent symbols) should
resolve to zero.
Also, make sure to not include function in the indirect function
table if they are not included in the output.
Differential Revision: https://reviews.llvm.org/D41839
llvm-svn: 322045
Add attribute target multiversioning to the release notes.
Additionally adds multiversioning support to the attribute
documentation for 'target'.
Differential Revision: https://reviews.llvm.org/D41837
llvm-svn: 322043
Currently LLVM's paralellForEach has a problem with reentracy.
That caused https://bugs.llvm.org/show_bug.cgi?id=35788 (lld somtimes
hangs while linking Ruby 2.4) because maybeCompress calls writeTo which
uses paralellForEach.
This patch is to avoid using paralellForEach to call maybeCompress
to workaround the issue.
llvm-svn: 322041
These tests started failing because we now properly convert
DefRange records to and from Yaml, but there were some old yaml
files that had incorrect record definitions generated by the
old buggy obj2yaml. Rather than try to re-generate the yaml files,
it's easier to just remove the records, and they weren't necessary
for the proper execution of the test anyway.
llvm-svn: 322040
Seems to have broken some tests since I first wrote this a while
back. Will reland after checking what went wrong with the tests.
This reverts commit 7023194c8d11a081fd01ed25308b3d60193c6a06.
llvm-svn: 322039
I'm going to convert these to 'icmp slt X, zeroinitializer' in clang's CGBuiltin.cpp, but the GCCBuiltin names need to be removed to do that.
llvm-svn: 322037
This patch makes the following changes to the schedule of instructions in the
prologue and epilogue.
The stack pointer update is moved down in the prologue so that the callee saves
do not have to wait for the update to happen.
Saving the lr is moved down in the prologue to hide the latency of the mflr.
The stack pointer is moved up in the epilogue so that restoring of the lr can
happen sooner.
The mtlr is moved up in the epilogue so that it is away form the blr at the end
of the epilogue. The latency of the mtlr can now be hidden by the loads of the
callee saved registers.
Differential Revision: https://reviews.llvm.org/D41737
llvm-svn: 322036
The body of the in scanRelocs is fairly big. This moves it to its own
function.
It is not a big readability win by itself, but should help further
refactoring.
llvm-svn: 322035
If the make program isn't in the path, the native configure will fail.
Pass CMAKE_MAKE_PROGRAM to the native configure explicitly to remedy
this, similar to what's already done for external project configuration.
Explicitly set CMAKE_MAKE_PROGRAM before the user flags so that they can
override it for the native build if they desire (though I can't fathom
why that would be useful).
llvm-svn: 322032
The problem was that our Obj -> Yaml dumper had not been taught
to handle certain types of records. This meant that when I
generated the test input files, the records were still there but
none of its fields were filled out. So when it did the
Yaml -> Obj conversion as part of the test, it generated records
with garbage in them.
The patch here fixes the Obj <-> Yaml converter, and additionally
updates the test file with fresh Yaml generated by the fixed
converter.
llvm-svn: 322029
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".
- Fix a few typos and errors found during review.
- Restore new line endings.
This patch was made by Craig Flores
llvm-svn: 322027
It was being set but never used, and its value is only ever needed
locally in lld::coff::link.
Differential Revision: https://reviews.llvm.org/D41814
llvm-svn: 322026
This is not quite NFC: we don't perform the usual arithmetic conversions unless
we have an operand of arithmetic or enumeration type any more. This matches the
standard rule, but actually has no effect other than to marginally improve our
diagnostics for the non-arithmetic, non-enumeration cases (by not performing
integral promotions on one operand if the other is a pointer).
llvm-svn: 322024
Summary:
The flag has been deprecated, and is becoming invalid in the latest
MDK.
Reviewers: jyknight
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41713
llvm-svn: 322023
Add test/DebugInfo/MIR/Mips/lit.local.cfg so no tests are run if Mips is
not a supported target.
This should resolve buildbot failures seen after r322015.
llvm-svn: 322020
Summary: Some info about supported features of OpenMP 4.5-5.0.
Reviewers: hfinkel, rsmith
Subscribers: kkwli0, Hahnfeld, cfe-commits
Differential Revision: https://reviews.llvm.org/D39457
llvm-svn: 322018
Paul Osmialowski