This should actually address PR27855. This results in adding references to the system libs inside generated dylibs so that they get correctly pulled in when linking against the dylib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270723 91177308-0d34-0410-b5e6-96231b3b80d8
LegalizeIntegerTypes does not have a way to expand multiplications for large
integer types (i.e. larger than twice the native bit width). There's no
standard runtime call to use in that case, and so we'd just assert.
Unfortunately, as it turns out, it is possible to hit this case from
standard-ish C code in rare cases. A particular case a user ran into yesterday
involved an __int128 induction variable and a loop with a quadratic (not
linear) recurrence which triggered some backend logic using SCEVExpander. In
this case, the BinomialCoefficient code in SCEV generates some i129 variables,
which get widened to i256. At a high level, this is not actually good (i.e. the
underlying optimization, PPCLoopPreIncPrep, should not be transforming the loop
in question for performance reasons), but regardless, the backend shouldn't
crash because of cost-modeling issues in the optimizer.
This is a straightforward implementation of the multiplication expansion, based
on the algorithm in Hacker's Delight. I validated it against the code for the
mul256b function from http://locklessinc.com/articles/256bit_arithmetic/ using
random inputs. There should be no functional change for previously-working code
(the new expansion code only replaces an assert).
Fixes PR19797.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270720 91177308-0d34-0410-b5e6-96231b3b80d8
There aren't any checks with prefix PROMOTE, should be PROMOTE_MOD1
which wasn't being tested (but works as expected).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270719 91177308-0d34-0410-b5e6-96231b3b80d8
searching for external symbols, and fall back to the SymbolResolver::findSymbol
method if the former returns null.
This makes RuntimeDyld behave more like a static linker: Symbol definitions
from within the current module's "logical dylib" will be preferred to
external definitions. We can build on this behavior in the future to properly
support weak symbol handling.
Custom symbol resolvers that override the findSymbolInLogicalDylib method may
notice changes due to this patch. Clients who have not overridden this method
should generally be unaffected, however users of the OrcMCJITReplacement class
may notice changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270716 91177308-0d34-0410-b5e6-96231b3b80d8
Also, rename recognizeBitReverseOrBSwapIdiom to recognizeBSwapOrBitReverseIdiom,
so the ordering of the MatchBSwaps and MatchBitReversals arguments are
consistent with the function name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270715 91177308-0d34-0410-b5e6-96231b3b80d8
Move the now index-based ODR resolution and internalization routines out
of ThinLTOCodeGenerator.cpp and into either LTO.cpp (index-based
analysis) or FunctionImport.cpp (index-driven optimizations).
This is to enable usage by other linkers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270698 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
**Description**
This makes `WidenIV::widenIVUse` (IndVarSimplify.cpp) fail to widen narrow IV uses in some cases. The latter affects IndVarSimplify which may not eliminate narrow IV's when there actually exists such a possibility, thereby producing ineffective code.
When `WidenIV::widenIVUse` gets a NarrowUse such as `{(-2 + %inc.lcssa),+,1}<nsw><%for.body3>`, it first tries to get a wide recurrence for it via the `getWideRecurrence` call.
`getWideRecurrence` returns recurrence like this: `{(sext i32 (-2 + %inc.lcssa) to i64),+,1}<nsw><%for.body3>`.
Then a wide use operation is generated by `cloneIVUser`. The generated wide use is evaluated to `{(-2 + (sext i32 %inc.lcssa to i64))<nsw>,+,1}<nsw><%for.body3>`, which is different from the `getWideRecurrence` result. `cloneIVUser` sees the difference and returns nullptr.
This patch also fixes the broken LLVM tests by adding missing <nsw> entries introduced by the correction.
**Minimal reproducer:**
```
int foo(int a, int b, int c);
int baz();
void bar()
{
int arr[20];
int i = 0;
for (i = 0; i < 4; ++i)
arr[i] = baz();
for (; i < 20; ++i)
arr[i] = foo(arr[i - 4], arr[i - 3], arr[i - 2]);
}
```
**Clang command line:**
```
clang++ -mllvm -debug -S -emit-llvm -O3 --target=aarch64-linux-elf test.cpp -o test.ir
```
**Expected result:**
The ` -mllvm -debug` log shows that all the IV's for the second `for` loop have been eliminated.
Reviewers: sanjoy
Subscribers: atrick, asl, aemerson, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D20058
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270695 91177308-0d34-0410-b5e6-96231b3b80d8
There's already a ARMTargetParser,now adding a similar one for aarch64.
so we can use it to do ARCH/CPU/FPU parsing in clang and llvm, instead of
string comparison.
Patch by Jojo Ma.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270687 91177308-0d34-0410-b5e6-96231b3b80d8
A volatile load has side effects beyond what callers expect readonly to
signify. For example, it is not safe to reorder two function calls
which each perform a volatile load to the same memory location.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270671 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure that the unused fields are explicitly stated when defining the types.
Add some compile time assertions about the size requirements for the structure
types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270663 91177308-0d34-0410-b5e6-96231b3b80d8
name_ids() did not return all IDs but only the first NameCount items.
The number of non-zero entries in IDs vector is NameCount, but it
does not mean that all non-zero entries are at the beginning of IDs
vector.
Differential Revision: http://reviews.llvm.org/D20611
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270656 91177308-0d34-0410-b5e6-96231b3b80d8
Try to figure out what each stream is, and dump its name.
This gives us a better picture of what streams we still don't
understand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270653 91177308-0d34-0410-b5e6-96231b3b80d8
This is a support COFF feature. Ensure that we can display the weak externals
auxiliary symbol. It contains useful information (such as the default binding
and how to resolve the symbol).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270648 91177308-0d34-0410-b5e6-96231b3b80d8
[AMDGPU] emitPrologue looks for an unused unallocated SGPR that is not
the scratch descriptor. Continue search if unused register found fails
other requirements.
Reviewers: arsenm, tstellarAMD, nhaehnle
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D20526
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270646 91177308-0d34-0410-b5e6-96231b3b80d8
We have to modify V2SU before inserting new elements into the
CurrentVRegDefs set because that may move V2SU in memory invalidating
the reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270644 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Adds fastpath instrumentation for esan's working set tool. The
instrumentation for an intra-cache-line load or store consists of an
inlined write to shadow memory bits for the corresponding cache line.
Adds a basic test for this instrumentation.
Reviewers: aizatsky
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits
Differential Revision: http://reviews.llvm.org/D20483
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270640 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for:
S_EXPORT
LF_BITFIELD
With this patch, I have run through a couple of gigabytes of PDB
files and cannot find a type or symbol that we do not understand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270637 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of this:
i32.const $push10=, __stack_pointer
i32.load $push11=, 0($pop10)
Emit this:
i32.const $push10=, 0
i32.load $push11=, __stack_pointer($pop10)
It's not currently clear which is better, though there's a chance the second
form may be better at overall compression. We can revisit this when we have
more data; for now it makes sense to make PEI consistent with isel.
Differential Revision: http://reviews.llvm.org/D20411
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270635 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for parsing and dumping the following
symbol types:
S_LPROCREF
S_ENVBLOCK
S_COMPILE2
S_REGISTER
S_COFFGROUP
S_SECTION
S_THUNK32
S_TRAMPOLINE
As of this patch, the test PDB files no longer have any unknown
symbol types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270628 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Adds createEsanInitToolGV for creating a tool-specific variable passed
to the runtime library.
Adds dtor "esan.module_dtor" and inserts calls from the dtor to
"__esan_exit" in the runtime library.
Updates the EfficiencySanitizer test.
Patch by Qin Zhao.
Reviewers: aizatsky
Subscribers: bruening, kcc, vitalybuka, eugenis, llvm-commits
Differential Revision: http://reviews.llvm.org/D20488
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270627 91177308-0d34-0410-b5e6-96231b3b80d8
The benefits of this patch are
-- We call AnalyzeBranch() to optimize unanalyzable branches, but the result of
AnalyzeBranch() is not used. Now the result is useful.
-- Before the layout of all the MBBs is set, the result of AnalyzeBranch() is
not correct and needs to be fixed before using it to optimize the branch
conditions. Now this optimization is called after the layout, the code used
to fix the result of AnalyzeBranch() is not needed.
-- The branch condition of the last block is not optimized before. Now it is
optimized.
Differential Revision: http://reviews.llvm.org/D20177
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270623 91177308-0d34-0410-b5e6-96231b3b80d8
