| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the use optimizer, we need to keep of whether the lower bound still
dominates us or else we may decide a lower bound is still valid when it
is not due to intervening pushes/pops. Fixes PR28880 (and probably a
bunch of other things).
Reviewers: george.burgess.iv
Subscribers: MatzeB, llvm-commits, sebpop
Differential Revision: https://reviews.llvm.org/D23237
llvm-svn: 277978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The correctness fix here is that when we CSE a load with another load,
we need to combine the metadata on the two loads. This matches the
behavior of other passes, like instcombine and GVN.
There's also a minor optimization improvement here: for load PRE, the
aliasing metadata on the inserted load should be the same as the
metadata on the original load. Not sure why the old code was throwing
it away.
Issue found by inspection.
Differential Revision: http://reviews.llvm.org/D21460
llvm-svn: 277977
|
| |
|
|
|
|
|
| |
Jim Grosbach and Kevin Enderby think those are not used anymore.
Originally submitted by: Rafael Espindola
llvm-svn: 277973
|
| |
|
|
| |
llvm-svn: 277972
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
PromoteMemToReg looks specifically for the pattern
bitcast+lifetime.start (or a bitcast-equivalent GEP); any offset
will lead to an assertion failure.
Fixes https://llvm.org/bugs/show_bug.cgi?id=27999 .
Differential Revision: https://reviews.llvm.org/D22737
llvm-svn: 277969
|
| |
|
|
|
|
| |
of a 512-bit vector of zeroes by using vmovq/vmovd/vmovss/vmovsd.
llvm-svn: 277965
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22104
llvm-svn: 277963
|
| |
|
|
| |
llvm-svn: 277962
|
| |
|
|
|
|
| |
stack folding test and move some tests from the avx512vl test.
llvm-svn: 277961
|
| |
|
|
|
|
| |
folding tables.
llvm-svn: 277960
|
| |
|
|
|
|
|
|
| |
SM_SentinelUndef
Help lowering and combining (which can specify SM_SentinelZero mask elements) share more shuffle matching code.
llvm-svn: 277959
|
| |
|
|
|
|
|
|
|
|
|
| |
integer values
Optimized lowering of BITCAST node. The BITCAST node can be replaced with COPY_TO_REG instead of KMOV.
It allows to suppress two opposite BITCAST operations and avoid redundant "movs".
Differential Revision: https://reviews.llvm.org/D23247
llvm-svn: 277958
|
| |
|
|
| |
llvm-svn: 277957
|
| |
|
|
| |
llvm-svn: 277956
|
| |
|
|
|
|
|
|
|
|
| |
This is a new test that should explore a current suboptimal sequence in passing values between cmp and kor intrinsics.
The code will be optimized in an upcoming patch.
Submitted bug here:
https://llvm.org/bugs/show_bug.cgi?id=28839
llvm-svn: 277954
|
| |
|
|
| |
llvm-svn: 277952
|
| |
|
|
|
|
|
| |
Simplify ptrtoint comparisons involving operands with different source
types.
llvm-svn: 277951
|
| |
|
|
| |
llvm-svn: 277950
|
| |
|
|
|
|
| |
tables.
llvm-svn: 277949
|
| |
|
|
| |
llvm-svn: 277948
|
| |
|
|
| |
llvm-svn: 277947
|
| |
|
|
|
|
|
|
|
| |
loops.""
This reverts commit r277901. Reaaply the commit as it looks like it has
nothing to do with the bots failures.
llvm-svn: 277946
|
| |
|
|
|
|
|
|
|
| |
RuntimeDyld.
JITSymbol really belongs in RuntimeDyld. This should fix the llvm-rtdyld link
failures caused by r277943.
llvm-svn: 277945
|
| |
|
|
| |
llvm-svn: 277944
|
| |
|
|
| |
llvm-svn: 277943
|
| |
|
|
|
|
| |
on linux last time.
llvm-svn: 277942
|
| |
|
|
| |
llvm-svn: 277941
|
| |
|
|
| |
llvm-svn: 277940
|
| |
|
|
|
|
| |
Split extensions to large vectors into 256-bit chunks - the equivalent of what we do with pre-AVX2 into 128-bit chunks
llvm-svn: 277939
|
| |
|
|
| |
llvm-svn: 277938
|
| |
|
|
| |
llvm-svn: 277937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CoroSplit pass processes the coroutine twice. First, it lets it go through
complete IPO optimization pipeline as a single function. It forces restart
of the pipeline by inserting an indirect call to an empty function "coro.devirt.trigger"
which is devirtualized by CoroElide pass that triggers a restart of the pipeline by CGPassManager.
(In later patches, when CoroSplit pass sees the same coroutine the second time, it splits it up,
adds coroutine subfunctions to the SCC to be processed by IPO pipeline.)
Documentation and overview is here: http://llvm.org/docs/Coroutines.html.
Upstreaming sequence (rough plan)
1.Add documentation. (https://reviews.llvm.org/D22603)
2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659)
3.Add empty coroutine passes. (https://reviews.llvm.org/D22847)
4.Add coroutine devirtualization + tests.
ab) Lower coro.resume and coro.destroy (https://reviews.llvm.org/D22998)
c) Do devirtualization (https://reviews.llvm.org/D23229)
5.Add CGSCC restart trigger + tests. <= we are here
6.Add coroutine heap elision + tests.
7.Add the rest of the logic (split into more patches)
Reviewers: mehdi_amini, majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23234
llvm-svn: 277936
|
| |
|
|
| |
llvm-svn: 277934
|
| |
|
|
| |
llvm-svn: 277933
|
| |
|
|
|
|
| |
commits will refine some of the sequences.
llvm-svn: 277932
|
| |
|
|
|
|
| |
hasUndefRegUpdate.
llvm-svn: 277931
|
| |
|
|
|
|
|
|
| |
Assuming SSE2 is available then we can safely commute between these, removing some unnecessary register moves and improving memory folding opportunities.
VEX encoded versions don't benefit so I haven't added support to them.
llvm-svn: 277930
|
| |
|
|
| |
llvm-svn: 277927
|
| |
|
|
| |
llvm-svn: 277925
|
| |
|
|
| |
llvm-svn: 277924
|
| |
|
|
| |
llvm-svn: 277922
|
| |
|
|
| |
llvm-svn: 277921
|
| |
|
|
|
|
| |
Not actually used yet...
llvm-svn: 277919
|
| |
|
|
| |
llvm-svn: 277916
|
| |
|
|
|
|
|
| |
A parameter was documented with the wrong name.
No functionality change is intended.
llvm-svn: 277915
|
| |
|
|
|
|
|
| |
Reasoning about a select in terms of a min or max allows us to derive a
tigher bound on the result.
llvm-svn: 277914
|
| |
|
|
|
|
| |
No functional change is intended.
llvm-svn: 277913
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current approach isn't a long-term viable pattern. Given the set of
architectures A, vendors V, operating systems O, and environments E, it
does |A| * |V| * |O| * |E| * 4! tests. As LLVM grows, this test keeps
getting slower, despite my working very hard to make it get some
"optimizations" even in -O0 builds in order to lower the constant
factors. Fundamentally, we're doing an unreasonable amount of work.i
Looking at the specific thing being tested -- the goal seems very
clearly to be testing the *permutations*, not the *combinations*. The
combinations are driving up the complexity much more than anything else.
Instead, test every possible value for a given triple entry in every
permutation of *some* triple. This really seems to cover the core goal
of the test. Every single possible triple component is tested in every
position. But because we keep the rest of the triple constant, it does
so in a dramatically more scalable amount of time. With this model we do
(|A| + |V| + |O| + |E|) * 4! tests.
For me on a debug build, this goes from running for 19 seconds to 19
milliseconds, or a 1000x improvement. This makes a world of difference
for the critical path of 'ninja check-llvm' and other extremely common
workflows.
Thanks to Renato, Dean, and David for the helpful review comments and
helping me refine the explanation of the change.
Differential Revision: https://reviews.llvm.org/D23156
llvm-svn: 277912
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: majnemer
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D23231
llvm-svn: 277910
|
| |
|
|
|
|
|
|
|
|
|
| |
GVN-Hoist appears to miscompile llvm-testsuite
SingleSource/Benchmarks/Misc/fbench.c at the moment.
I filed http://llvm.org/PR28880
This reverts commit r277786.
llvm-svn: 277909
|