| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 279845
|
|
|
|
| |
llvm-svn: 279844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's unclear how the old
%res(32) = G_ICMP { s32, s32 } intpred(eq), %0, %1
is actually different from an s1 verison
%res(1) = G_ICMP { s1, s32 } intpred(eq), %0, %1
so we'll remove it for now.
llvm-svn: 279843
|
|
|
|
| |
llvm-svn: 279842
|
|
|
|
| |
llvm-svn: 279841
|
|
|
|
| |
llvm-svn: 279840
|
|
|
|
| |
llvm-svn: 279839
|
|
|
|
|
|
|
|
| |
1. Early exit to reduce indent
2. Fix comments and variable names to match
3. Reformat comments / clang-format code
llvm-svn: 279837
|
|
|
|
| |
llvm-svn: 279836
|
|
|
|
| |
llvm-svn: 279835
|
|
|
|
| |
llvm-svn: 279834
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Dead store elimination gets very expensive when large numbers of instructions need to be analyzed. This patch limits the number of instructions analyzed per store to the value of the memdep-block-scan-limit parameter (which defaults to 100). This resulted in no observed difference in performance of the generated code, and no change in the statistics for the dead store elimination pass, but improved compilation time on some files by more than an order of magnitude.
Reviewers: dexonsmith, bruno, george.burgess.iv, dberlin, reames, davidxl
Subscribers: davide, chandlerc, dberlin, davidxl, eraman, tejohnson, mbodart, llvm-commits
Differential Revision: https://reviews.llvm.org/D15537
llvm-svn: 279833
|
|
|
|
| |
llvm-svn: 279831
|
|
|
|
| |
llvm-svn: 279830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't mark ORE (a function pass) preserved as required by the loop
passes because that is how we ensure that the required passes like
LazyBFI are all available any time ORE is used. See the new comments in
the patch.
Instead we use it directly just like the inliner does in D22694.
As expected there is some additional overhead after removing the caching
provided by analysis passes. The worst case, I measured was
LNT/CINT2006_ref/401.bzip2 which regresses by 12%. As before, this only
affects -Rpass-with-hotness and not default compilation.
llvm-svn: 279829
|
|
|
|
|
|
|
|
|
|
|
| |
Removing the redundant 'CmpRHSV' local variable exposes a bug in the caller
foldICmpShrConstant() - it was sending in the div constant instead of the
cmp constant. But I have not been able to expose this in a regression test
yet - the affected folds all appear to be handled before we ever reach this
code. I'll keep trying to find a case as I make changes to allow vector folds
in both functions.
llvm-svn: 279828
|
|
|
|
| |
llvm-svn: 279823
|
|
|
|
|
|
|
|
| |
This is similar to what was done in r261675, but for CSINC rather than CSINV.
Differential Revision: https://reviews.llvm.org/D23892
llvm-svn: 279822
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In fuctions that contained debug info but were empty otherwise,
the ARM load/store optimizer could abort. This was because
function MergeReturnIntoLDM handled the special case where a
Machine Basic BLock is empty by calling MBB.empty(). However, this
returns false in presence of debug info, although the function
should be considered empty in the eyes of the load/store optimizer.
This has been fixed by handling the case where searching through the
block finds only debug instructions.
Reviewers: rengolin, dexonsmith, llvm-commits, jmolloy
Subscribers: t.p.northover, aemerson, rengolin, samparker
Differential Revision: https://reviews.llvm.org/D23847
llvm-svn: 279820
|
|
|
|
|
|
| |
integer domain
llvm-svn: 279811
|
|
|
|
|
|
|
|
|
| |
This function allows getting arbitrary sized block of random bytes.
Primary motivation is support for --build-id=uuid in lld.
Differential revision: https://reviews.llvm.org/D23671
llvm-svn: 279807
|
|
|
|
| |
llvm-svn: 279806
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was for some reason skipping operands that are subregisters
instead of keeping the same subregister index.
v_movreld_b32 expects src0 to be the subregister of the tied
super register use/def.
e.g.
v_movreld_b32 v0, v9, <imp-def, tied3> v[0:3], <imp-use, tied2> v[0:3]
was being replaced with
v[4:7] = copy v[0:3]
v_movreld_b32 v0, v9, <imp-def, tied3> v[4:7], <imp-use, tied2> v[4:7],
which really writes to v[0:3]
llvm-svn: 279804
|
|
|
|
| |
llvm-svn: 279796
|
|
|
|
| |
llvm-svn: 279792
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts most of r274613 (AKA r274626) and its follow-ups (r276347, r277289),
due to miscompiles in the test suite. The FastISel change was left in, because
it apparently fixes an unrelated issue.
(Recommit of r279782 which was broken due to a bad merge.)
This fixes 4 out of the 5 test failures in PR29112.
llvm-svn: 279788
|
|
|
|
|
|
| |
useful: print PCs only after the initial corpus has been read and symbolize them
llvm-svn: 279787
|
|
|
|
| |
llvm-svn: 279785
|
|
|
|
|
|
|
|
|
|
| |
This reverts most of r274613 and its follow-ups (r276347, r277289), due to
miscompiles in the test suite. The FastISel change was left in, because it
apparently fixes an unrelated issue.
This fixes 4 out of the 5 test failures in PR29112.
llvm-svn: 279782
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23846
llvm-svn: 279778
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Its existence is largely historical, apparently we tried to make ARM object
files look maybe-almost-possibly runnable by putting our best guess at the
actual value into relocated locations. Of course, the real linker then comes
along and can completely change things.
But it should only be there for word-sized and movw/movt relocations. It can't
be encoded in branch relocations, and I've seen it mess up validity
calculations twice in the last couple of weeks so the default is clearly problematic.
llvm-svn: 279773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
identity of two operands
Summary:
This fixes pr29105. The reason is that lifetime marks creates new
aliasing pointers the original ones, but before this patch aliases
were not checked in performMemCpyToMemSetOptzn.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23846
llvm-svn: 279769
|
|
|
|
| |
llvm-svn: 279767
|
|
|
|
| |
llvm-svn: 279762
|
|
|
|
|
|
| |
It's expected this will map to NZCV register class and be properly selectable.
llvm-svn: 279761
|
|
|
|
|
|
|
|
| |
The 32-bit variants of these operations don't depend on the bits not being
operated on, so they also naturally model operations narrower than the actual
register width.
llvm-svn: 279760
|
|
|
|
| |
llvm-svn: 279759
|
|
|
|
| |
llvm-svn: 279758
|
|
|
|
| |
llvm-svn: 279757
|
|
|
|
|
|
|
|
|
| |
Fix VPAVG detection to require AVX512BW, not AVX512F for 512-bit widths,
and change associated asserts to assert in the right direction...
This fixes PR29111.
llvm-svn: 279755
|
|
|
|
| |
llvm-svn: 279751
|
|
|
|
|
|
| |
BB# ...
llvm-svn: 279750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when unroll runtime iteration loop.
In llvm::UnrollRuntimeLoopRemainder, if the loop to be unrolled is the inner
loop inside a loop nest, the scalar evolution needs to be dropped for its
parent loop which is done by ScalarEvolution::forgetLoop. However, we can
postpone forgetLoop to the end of UnrollRuntimeLoopRemainder so TripCountSC
expansion can still reuse existing value.
Differential Revision: https://reviews.llvm.org/D23572
llvm-svn: 279748
|
|
|
|
| |
llvm-svn: 279745
|
|
|
|
|
|
|
|
| |
Add vector store print tracing option for hexagon vector instructions.
https://reviews.llvm.org/D23870
llvm-svn: 279739
|
|
|
|
|
|
| |
Fix for PR29133, matching the approach that was taken for AVX1 scalar broadcasts.
llvm-svn: 279735
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is invalid to hoist stores or loads if they are not executed on all paths
from the hoisting point to the exit of the function. In the testcase, there are
paths in the loop that do not execute the stores or the loads, and so hoisting
them within the loop is unsafe.
The problem is that the current implementation of hoistingFromAllPaths is
incomplete: it walks all blocks dominated by the hoisting point, and does not
return false when the loop contains a path on which the hoisted ld/st is
not executed.
Differential Revision: https://reviews.llvm.org/D23843
llvm-svn: 279732
|
|
|
|
|
|
| |
There's no reason for it to return a signed type. Just return the operand bias in each if instead of starting from 0 and adding in the 'if'.
llvm-svn: 279720
|
|
|
|
| |
llvm-svn: 279719
|
|
|
|
|
|
| |
"warning: extra ‘;’ [-Wpedantic]"
llvm-svn: 279703
|