The idea here is to provide a customizable install target that only depends on building the things you actually want to install. It relies on each component being installed having an auto-generated install-${component}, which in turn depends only on the target being installed.
This is fundamentally a workaround for the fact that CMake generates build files which have their "install" target depend on the "all" target. This results in "ninja install" building a bunch of unneeded things.
llvm-svn: 261681
This change migrates clang-format to add_clang_tool which makes a component-based install target. To support component-based installation the extra installed scripts all need to have the "clang-format" component too.
llvm-svn: 261680
We were emitting only one half of a the paired relocations needed for these
instructions because we decided that an offset needed a scattered relocation.
In fact, movw/movt relocations can be paired without being scattered.
llvm-svn: 261679
There is nothing aarch64 specific in here. If a symbol can be preempted,
we need to copy the full relocation to the dynamic linker.
If a symbol cannot be preempted, we can make the dynamic linker life
easier and produce a relative relocation.
This is directly equivalent to R_X86_64_64 to R_x86_64_RELATIVE
conversion.
llvm-svn: 261678
Also introduce inputs() that reutnrs an llvm::iterator_range.
Iterating over A->inputs() is much less mysterious than
iterating over *A. No intended behavior change.
llvm-svn: 261674
Remove an unnecessary workaround introduced in r259975. (NFC)
Now that LLVM r259973 allows replacing a temporary type with another
temporary we can rely on the original implementation.
It is possible for enums to be created as part of
their own declcontext. In this case a FwdDecl will be created
twice. This doesn't cause a problem because both FwdDecls are
entered into the ReplaceMap: finalize() will replace the first
FwdDecl with the second and then replace the second with
complete type.
Thanks to echristo for pointing this out.
# Conflicts:
# lib/CodeGen/CGDebugInfo.cpp
llvm-svn: 261673
The .tbss section is in the middle of a PT_LOAD. Whatever treatment we
give to its address we must also give to the offset.
We were ignoring it for address computations, but not for offset.
Fixes pr26712.
llvm-svn: 261667
Summary:
Currently, the ARM Constant Island may not converge (or not converge quickly).
This patch let it move to the closest water after the user if it doesn't converge after 15 iterations.
This address https://llvm.org/bugs/show_bug.cgi?id=25339
Reviewers: t.p.northover, srhines, kristof.beyls, aadg, rengolin
Subscribers: weimingz, aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D16890
llvm-svn: 261665
This patch moves BitcodeFile instantiation into createObjectFile.
Previously, we handle bitcode files outside that function and did
not handle for --whole-archive.
http://reviews.llvm.org/D17527
llvm-svn: 261663
Implements a mostly-conventional redzone for the userspace
stack. Because we have unsigned load/store offsets we continue to use a
local SP subtracted from the incoming SP but do not write it back to
memory.
Differential Revision: http://reviews.llvm.org/D17525
llvm-svn: 261662
The first issue is that we longjmp from ScopedInterceptor scope
when called from an ignored lib. This leaves thr->in_ignored_lib set.
This, in turn, disables handling of sigaction. This, in turn,
corrupts tsan state since signals delivered asynchronously.
Another issue is that we can ignore synchronization in asignal
handler, if the signal is delivered into an IgnoreSync region.
Since signals are generally asynchronous, they should ignore
memory access/synchronization/interceptor ignores.
This could lead to false positives in signal handlers.
llvm-svn: 261658
Now that LLVM r259973 allows replacing a temporary type with another
temporary we can rely on the original implementation.
It is possible for enums to be created as part of
their own declcontext. In this case a FwdDecl will be created
twice. This doesn't cause a problem because both FwdDecls are
entered into the ReplaceMap: finalize() will replace the first
FwdDecl with the second and then replace the second with
complete type.
Thanks to echristo for pointing this out.
llvm-svn: 261657
It is problematic if the inlinee has a cleanupret which unwinds to
caller and we inline it into a call site which doesn't unwind.
If the funclet unwinds anywhere other than to the caller,
then we will give the funclet two unwind destinations.
This will result in a verifier failure.
Seeing as how the caller wasn't an invoke (which would locally unwind)
and that the funclet cannot unwind to caller, we must conclude that an
'unwind to caller' cleanupret is dynamically unreachable.
This fixes PR26698.
Differential Revision: http://reviews.llvm.org/D17536
llvm-svn: 261656
This patch fixes the R_AARCH64_ABS64 relocation when used in shared mode,
where it requires a dynamic R_AARCH64_RELATIVE relocation. To correct set
the addend on the dynamic relocation (since it will be used by the dynamic
linker), a new TargetInfo specific hook was created (getDynRelativeAddend)
to get the correct addend based on relocation type.
The patch fixes the issues when creating shared library code against
{init,fini}_array, where it issues R_AARCH64_ABS64 relocation against
local symbols.
llvm-svn: 261651
Summary:
Fix a bug in epilog generation where the incoming stack arguments were
not being popped for fastcc functions when -tailcallopt was passed.
Reviewers: t.p.northover, mcrosier, jmolloy, rengolin
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16894
llvm-svn: 261650
This is a straight cut and paste of the existing code and is intended to
be the first step in solving part of PR26702:
https://llvm.org/bugs/show_bug.cgi?id=26702
We should be able to reuse most of this and delete the nearly identical
existing code in visitOr(). Then, we can enhance visitXor() to use the
same code too.
llvm-svn: 261649
The scalar float/double function bodies are a direct copy/paste
with usage of the CLC wrappers to vectorize them.
This commit also adds in the FP_ILOGB0 and FP_ILOGBNAN macros which are
equal to the results of ilogb(0.0f) and ilogb(float nan) respectively.
v2: Add FP_ILOGB0 and FP_ILOGBNAN definitions
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
v1 Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 261639
Summary:
On arm64, linux<=4.4 and Android<=M there is a bug, which prevents single-stepping from working when
the system comes back from suspend, because of incorrectly initialized CPUs. This did not really
affect Android<M, because it did not use software suspend, but it is a problem for M, which uses
suspend (doze) quite extensively. Fortunately, it seems that the first CPU is not affected by
this bug, so this commit implements a workaround by forcing the inferior to execute on the first
cpu whenever we are doing single stepping.
While inside, I have moved the implementations of Resume() and SingleStep() to the thread class
(instead of process).
Reviewers: tberghammer, ovyalov
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17509
llvm-svn: 261636
Rafael Espindola