RTDyldMemoryManager.cpp describes the differing __register_frame
API between libunwind and libgcc, with a mailing list posting URL.
The original link was 404; replace it with what I believe is the
intended post, as well as a reference to the "OS X" implementation in
libunwind.
Differential Revision: https://reviews.llvm.org/D27965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290269 91177308-0d34-0410-b5e6-96231b3b80d8
For vector GEPs, CastGEPIndices can end up in an infinite recursion, because
we compare the vector type to the scalar pointer type, find them different,
and then try to cast a type to itself.
Differential Revision: https://reviews.llvm.org/D28009
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290260 91177308-0d34-0410-b5e6-96231b3b80d8
I added API for creation a target specific memory node in DAG. Today, all memory nodes are common for all targets and their constructors are located in SelectionDAG.cpp.
There are some cases in X86 where we need to create a special node - truncation-with-saturation store, float-to-half-store.
In the current patch I added truncation-with-saturation nodes and I'm using them for intrinsics. In the future I plan to implement DAG lowering for truncation-with-saturation pattern.
Differential Revision: https://reviews.llvm.org/D27899
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290250 91177308-0d34-0410-b5e6-96231b3b80d8
The vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible.
vectorcall uses more registers for arguments than fastcall or the default x64 calling convention use.
The vectorcall calling convention is only supported in native code on x86 and x64 processors that include Streaming SIMD Extensions 2 (SSE2) and above.
The current implementation does not handle Homogeneous Vector Aggregates (HVAs) correctly and this review attempts to fix it.
This aubmit also includes additional lit tests to cover better HVAs corner cases.
Differential Revision: https://reviews.llvm.org/D27392
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290240 91177308-0d34-0410-b5e6-96231b3b80d8
In r267672, where the loop distribution pragma was introduced, I tried
it hard to keep the old behavior for opt: when opt is invoked
with -loop-distribute, it should distribute the loop (it's off by
default when ran via the optimization pipeline).
As MichaelZ has discovered this has the unintended consequence of
breaking a very common developer work-flow to reproduce compilations
using opt: First you print the pass pipeline of clang
with -debug-pass=Arguments and then invoking opt with the returned
arguments.
clang -debug-pass will include -loop-distribute but the pass is invoked
with default=off so nothing happens unless the loop carries the pragma.
While through opt (default=on) we will try to distribute all loops.
This changes opt's default to off as well to match clang. The tests are
modified to explicitly enable the transformation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290235 91177308-0d34-0410-b5e6-96231b3b80d8
we used to print UNKNOWN instructions when the instruction to be printer was not
yet inserted in any BB: in that case the pretty printer would not be able to
compute a TII as the instruction does not belong to any BB or function yet.
This patch explicitly passes the TII to the pretty-printer.
Differential Revision: https://reviews.llvm.org/D27645
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290228 91177308-0d34-0410-b5e6-96231b3b80d8
The usual method, and the one employed before my change, of displaying strings in natvis is to make use of the "<variable>,s" format specifier; however, this method only works for null-terminated strings. My fix here is to use the "<pointer>,[size]" format specifier to display a bounded array, and then cast it to "const char*", which in the MSVC debugger has the desired effect of rendering the character array as a string.
Differential Revision: https://reviews.llvm.org/D27972
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290224 91177308-0d34-0410-b5e6-96231b3b80d8
We're currently doing nearly the same thing for @llvm.objectsize in
three different places: two of them are missing checks for overflow,
and one of them could subtly break if InstCombine gets much smarter
about removing alloc sites. Seems like a good idea to not do that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290214 91177308-0d34-0410-b5e6-96231b3b80d8
GlobPattern is a class to handle glob pattern matching. Currently
only LLD is using that, but technically that feature is not specific
to linkers, so in this patch I move that file to LLVM.
Differential Revision: https://reviews.llvm.org/D27969
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290212 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In getRangeForAffineAR we compute ranges for affine exprs E = A + B*C,
where ranges for A, B, and C are known. To avoid overflow, we need to
operate on a bigger bitwidth, and originally we chose 2*x+1 for this
(x being the original bitwidth). However, it is safe to use just 2*x:
A+B*C <= (2^x - 1) + (2^x - 1)*(2^x - 1) =
= 2^x - 1 + 2^2x - 2^x - 2^x + 1 =
= 2^2x - 2^x <= 2^2x - 1
Unnecessary extending of bitwidths results in noticeable slowdowns: ranges
perform arithmetic operations using APInt, which are much slower when bitwidths
are bigger than 64.
Reviewers: sanjoy, majnemer, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27795
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290211 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for YAML<->DWARF for debug_info sections.
This re-lands r290147, after fixing the issue that caused bots to fail (thank you UBSan!).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290204 91177308-0d34-0410-b5e6-96231b3b80d8
When the instruction is processed the first time, it may be
deleted resulting in crashes. While the new test adds the same
user to the worklist twice, this particular case doesn't crash
but I'm not sure why.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290191 91177308-0d34-0410-b5e6-96231b3b80d8
By putting the assert behind a conditional in the initializer list
we can ensure that it will still work in a constexpr context as
the else branch of the ternary operator won't be examined unless
the condition fails.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290188 91177308-0d34-0410-b5e6-96231b3b80d8
I haven't managed to get this to fail yet but its technically possible for the AND -> shuffle decomposition to result in illegal types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290183 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Without a MachineMemOperand, the scheduler was assuming MIMG instructions
were ordered memory references, so no loads or stores could be reordered
across them.
Reviewers: arsenm
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D27536
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290179 91177308-0d34-0410-b5e6-96231b3b80d8
Include of llvm/IR/Verifier.h was removed from HexagonCommonGEP.cpp in r289604
as unused. In fact it is required when expensive checks are enabled, because
it declared function `verifyFunction`, which is called in conditionally compiled
part of the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290170 91177308-0d34-0410-b5e6-96231b3b80d8