| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
the instruction and operand instead of the Use.
The first thing it did was get the User for the Use to get the instruction back. This requires looking through the Uses for the User using the waymarking walk. That's pretty fast, but its probably still better to just pass the Instruction we already had.
llvm-svn: 298772
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When InstCombine is optimizing certain select-cmp-br patterns
it replaces the result of the select in uses outside of the
basic block containing the select. This is only legal if the
path from the select to the outside use is disjoint from all
other paths out from the originating basic block.
The problem found was that InstCombiner::replacedSelectWithOperand
did not consider the case when both edges out from the br pointed
to the same label. In that case the paths aren't disjoint and the
transformation is illegal. This patch avoids the faulty rewrites
by verifying that there is a single flow to the successor where
we want to replace uses.
Reviewers: llvm-commits, spatel, majnemer
Differential Revision: https://reviews.llvm.org/D30455
llvm-svn: 296752
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I found one special case of this transform for 'slt 0', so I removed that and added the general transform.
Alive code to check correctness:
Name: slt_no_overflow
Pre: WillNotOverflowSignedSub(C1, C2)
%a = add nsw i8 %x, C2
%b = icmp slt %a, C1
=>
%b = icmp slt %x, C1 - C2
Name: sgt_no_overflow
Pre: WillNotOverflowSignedSub(C1, C2)
%a = add nsw i8 %x, C2
%b = icmp sgt %a, C1
=>
%b = icmp sgt %x, C1 - C2
http://rise4fun.com/Alive/MH
Differential Revision: https://reviews.llvm.org/D29774
llvm-svn: 294898
|
| |
|
|
| |
llvm-svn: 294470
|
| |
|
|
|
|
|
| |
Requested by Sanjoy/Hal a while ago, and forgotten by me
(r283612).
llvm-svn: 294323
|
| |
|
|
| |
llvm-svn: 293652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transformToIndexedCompare
If they don't have the same type, the size of the constant
index would need to be adjusted (and this wouldn't be always
possible).
Alternatively we could try the analysis with the initial
RHS value, which would guarantee that the two sides have
the same type. However it is unlikely that in practice this
would pass our transformation requirements.
Fixes PR31808 (https://llvm.org/bugs/show_bug.cgi?id=31808).
llvm-svn: 293629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inf-loop (PR31751)
This is a minimal patch to avoid the infinite loop in:
https://llvm.org/bugs/show_bug.cgi?id=31751
But the general problem is bigger: we're not canonicalizing all of the min/max forms reported
by value tracking's matchSelectPattern(), and we don't define min/max consistently. Some code
uses matchSelectPattern(), other code uses matchers like m_Umax, and others have their own
inline definitions which may be subtly different from any of the above.
The reason that the test cases in this patch need a cast op to trigger is because we don't
(yet) canonicalize all min/max forms based on matchSelectPattern() in
canonicalizeMinMaxWithConstant(), but we do make min/max+cast transforms based on
matchSelectPattern() in visitSelectInst().
The location of the icmp transforms that trigger the inf-loop seems arbitrary at best, so
I'm moving those behind the min/max fence in visitICmpInst() as the quick fix.
llvm-svn: 293345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try harder to fold icmp with shl nsw as discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108749.html
This is similar to the 'shl nuw' transforms that were added with D25913.
This may eventually help solve:
https://llvm.org/bugs/show_bug.cgi?id=30773
Differential Revision: https://reviews.llvm.org/D28406
llvm-svn: 292492
|
| |
|
|
|
|
| |
explicit; NFCI
llvm-svn: 292440
|
| |
|
|
|
|
|
| |
I missed deleting this check when I refactored this chunk in:
https://reviews.llvm.org/rL292260
llvm-svn: 292433
|
| |
|
|
|
|
|
| |
This reduces the size of and increases the symmetry with the planned functional change in:
https://reviews.llvm.org/D28406
llvm-svn: 292260
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows LLVM to optimize sequences like the following:
%add = add nuw i32 %x, 1
%cmp = icmp ugt i32 %add, %y
Into:
%cmp = icmp uge i32 %x, %y
Previously, only signed comparisons were being handled.
Decrements could also be handled, but 'sub nuw %x, 1' is currently canonicalized to
'add %x, -1' in InstCombineAddSub, losing the nuw flag. Removing that canonicalization
seems like it might have far-reaching ramifications so I kept this simple for now.
Patch by Matti Niemenmaa!
Differential Revision: https://reviews.llvm.org/D24700
llvm-svn: 291975
|
| |
|
|
| |
llvm-svn: 291447
|
| |
|
|
|
|
|
|
| |
This is a follow-up to:
https://reviews.llvm.org/rL289855 (https://reviews.llvm.org/D27531)
https://reviews.llvm.org/rL290111
llvm-svn: 290118
|
| |
|
|
|
|
|
| |
This is a follow-up to:
https://reviews.llvm.org/rL289855 (D27531)
llvm-svn: 290111
|
| |
|
|
|
|
|
| |
This creates non-linear behavior in the inliner (see more details in
r289755's commit thread).
llvm-svn: 290086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Min/max canonicalization (r287585) exposes the fact that we're missing combines for min/max patterns.
This patch won't solve the example that was attached to that thread, so something else still needs fixing.
The line between InstCombine and InstSimplify gets blurry here because sometimes the icmp instruction that
we want to fold to already exists, but sometimes it's the swapped form of what we want.
Corresponding changes for smax/umin/umax to follow.
Differential Revision: https://reviews.llvm.org/D27531
llvm-svn: 289855
|
| |
|
|
|
|
|
|
|
| |
After r289755, the AssumptionCache is no longer needed. Variables affected by
assumptions are now found by using the new operand-bundle-based scheme. This
new scheme is more computationally efficient, and also we need much less
code...
llvm-svn: 289756
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
type.
Instead, expose whether the current type is an array or a struct, if an array
what the upper bound is, and if a struct the struct type itself. This is
in preparation for a later change which will make PointerType derive from
Type rather than SequentialType.
Differential Revision: https://reviews.llvm.org/D26594
llvm-svn: 288458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This transforms
%a = shl nuw %x, c1
%b = icmp {ugt|ule} %a, c0
into
%b = icmp {ugt|ule} %x, (c0 >> c1)
z3:
(declare-const x (_ BitVec 64))
(declare-const c0 (_ BitVec 64))
(declare-const c1 (_ BitVec 64))
(push)
(assert (= x (bvlshr (bvshl x c1) c1))) ; nuw
(assert (not (= (bvugt (bvshl x c1) c0)
(bvugt x
(bvlshr c0 c1)))))
(check-sat)
(get-model)
(pop)
(push)
(assert (= x (bvlshr (bvshl x c1) c1))) ; nuw
(assert (not (= (bvule (bvshl x c1) c0)
(bvule x
(bvlshr c0 c1)))))
(check-sat)
(get-model)
(pop)
Patch by bryant!
Differential Revision: https://reviews.llvm.org/D25913
llvm-svn: 285729
|
| |
|
|
|
|
|
|
|
|
| |
Fixes the FIXMEs in D25952 and rL285075.
Patch by bryant!
Differential Revision: https://reviews.llvm.org/D25955
llvm-svn: 285108
|
| |
|
|
|
|
| |
trunc transform
llvm-svn: 285075
|
| |
|
|
|
|
|
| |
ICmpInst::makeConstantRange does exactly the same thing as
ConstantRange::makeExactICmpRegion.
llvm-svn: 283059
|
| |
|
|
| |
llvm-svn: 281743
|
| |
|
|
|
|
| |
folds; NFCI
llvm-svn: 281672
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These 2 helper functions were already using APInt internally, so just
change the API and caller to allow folds for splats. The scalar
regression tests look quite thorough, so I just added a couple of
tests to prove that vectors are handled too.
These folds should be grouped with the other cmp+shift folds though.
That can be an NFC follow-up.
llvm-svn: 281663
|
| |
|
|
|
|
|
|
| |
canRewriteGEPAsOffset expects to process instructions, not constants.
This fixes PR30342.
llvm-svn: 281650
|
| |
|
|
| |
llvm-svn: 281644
|
| |
|
|
| |
llvm-svn: 281637
|
| |
|
|
|
|
| |
Also, clean up the code and comments for the existing folds in foldICmpSubConstant().
llvm-svn: 281631
|
| |
|
|
|
|
|
|
|
|
|
| |
This pattern is matched in foldICmpBinOpEqualityWithConstant() and already works
with vectors too. I changed some comments over there to point out the current
location. The tests for this transform are currently in 'sub.ll'.
Note that the remaining folds in this block all require a sub too, so they should
get grouped with the other icmp(sub) patterns.
llvm-svn: 281627
|
| |
|
|
| |
llvm-svn: 281624
|
| |
|
|
|
|
|
|
| |
1. Early exit to reduce indent
2. Rename variables
3. Add local 'Pred' variable
llvm-svn: 281615
|
| |
|
|
|
|
|
| |
This is a big glob of transforms that probably should work for vectors,
but currently they are disallowed because of ConstantInt guards.
llvm-svn: 281614
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 281613
|
| |
|
|
|
|
| |
The pattern matching and transforms are identical; the cmp predicate just changes.
llvm-svn: 281561
|
| |
|
|
|
|
| |
isSignBitCheck could be changed to take a pointer param to avoid the 'UnusedBit' ugliness.
llvm-svn: 281231
|
| |
|
|
| |
llvm-svn: 281220
|
| |
|
|
| |
llvm-svn: 281217
|
| |
|
|
| |
llvm-svn: 281214
|
| |
|
|
|
|
|
|
|
| |
foldICmpIntrinsicWithConstant ; NFC
1. Rename variables to be consistent with related/preceding code (may want to reorganize).
2. Fix comments/formatting.
llvm-svn: 281140
|
| |
|
|
|
|
|
|
|
|
| |
Everything under foldICmpInstWithConstant() should now be working for
splat vectors via m_APInt matchers. Ie, I've removed all of the FIXMEs
that I added while cleaning that section up. Note that not all of the
associated FIXMEs in the regression tests are gone though, because some
of the tests require earlier folds that are still scalar-only.
llvm-svn: 281139
|
| |
|
|
|
|
| |
vectors
llvm-svn: 281107
|
| |
|
|
|
|
|
|
|
|
|
| |
I introduced this potential bug by missing this diff in:
https://reviews.llvm.org/rL280873
...however, I'm not sure how to reach this code path with a regression test.
We may be able to remove this code and assume that the transform to a constant
is always handled by InstSimplify?
llvm-svn: 280964
|
| |
|
|
|
|
| |
splat constant vectors
llvm-svn: 280873
|
| |
|
|
|
|
|
|
| |
This is a revert of r280676 which was a revert of r280637;
ie, this is r280637 again. It was speculatively reverted to
help debug buildbot failures.
llvm-svn: 280861
|
| |
|
|
|
|
|
|
|
|
| |
This is effectively a revert of:
https://reviews.llvm.org/rL280115
And this should fix
https://llvm.org/bugs/show_bug.cgi?id=30281:
llvm-svn: 280677
|
| |
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/14952/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Aicmp.ll
llvm-svn: 280676
|