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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298772 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296752 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293629 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293345 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291975 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289855 91177308-0d34-0410-b5e6-96231b3b80d8
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...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289756 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288458 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281663 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281627 91177308-0d34-0410-b5e6-96231b3b80d8
This is a big glob of transforms that probably should work for vectors,
but currently they are disallowed because of ConstantInt guards.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281614 91177308-0d34-0410-b5e6-96231b3b80d8
1. Rename variables to be consistent with related/preceding code (may want to reorganize).
2. Fix comments/formatting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281140 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281139 91177308-0d34-0410-b5e6-96231b3b80d8
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?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280964 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280861 91177308-0d34-0410-b5e6-96231b3b80d8
