| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 322411
|
|
|
|
|
|
|
|
|
| |
This doesn't handle the more complicated case in the bug report yet:
https://bugs.llvm.org/show_bug.cgi?id=35790
For that, we have to match / look through a cast.
llvm-svn: 322327
|
|
|
|
| |
llvm-svn: 322323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
log(exp)
Summary: This patch enables folding following expressions under -ffast-math flag: exp(log(x)) -> x, exp2(log2(x)) -> x, log(exp(x)) -> x, log2(exp2(x)) -> x
Reviewers: spatel, hfinkel, davide
Reviewed By: spatel, hfinkel, davide
Subscribers: scanon, llvm-commits
Differential Revision: https://reviews.llvm.org/D41381
llvm-svn: 321710
|
|
|
|
|
|
|
|
|
|
| |
insertelement and extractelement
In one case, we were handling out of bounds, but not undef indices. In the other, we were handling undef (with the comment making the analogy to out of bounds), but not out of bounds. Be consistent and treat both undef and constant out of bounds indices as producing undefined results.
As a side effect, this also protects instcombine from having to handle large constant indices as we always simplify first.
llvm-svn: 321575
|
|
|
|
| |
llvm-svn: 321572
|
|
|
|
|
|
|
|
| |
APInt::getZExtValue()
Reduced from oss-fuzz #4768 test case
llvm-svn: 321454
|
|
|
|
|
|
| |
OpenGL issues should be fixed by now.
llvm-svn: 320568
|
|
|
|
|
|
|
| |
They were causing failures of the piglit OpenGL tests with AMD GPUs using the
Mesa radeonsi driver.
llvm-svn: 320466
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40650
llvm-svn: 320014
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
An undef extract index can be arbitrarily chosen to be an
out-of-range index value, which would result in the instruction being undef.
This change closes a gap identified while working on lowering vector permute intrinsics
with variable index vectors to pure LLVM IR.
Reviewers: arsenm, spatel, majnemer
Reviewed By: arsenm, spatel
Subscribers: fhahn, nhaehnle, wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D40231
llvm-svn: 319910
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40650
llvm-svn: 319894
|
|
|
|
|
|
|
|
|
|
|
| |
preceding dimensions
Follow-up of r316824. This patch supports the vector type for both current and
previous index when factoring out the current one into the previous one.
Differential Revision: https://reviews.llvm.org/D39556
llvm-svn: 319683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For known positive non-zero value X:
fcmp uge X, -C => true
fcmp ugt X, -C => true
fcmp une X, -C => true
fcmp oeq X, -C => false
fcmp ole X, -C => false
fcmp olt X, -C => false
Patch by Paul Walker.
Reviewers: majnemer, t.p.northover, spatel, RKSimon
Reviewed By: spatel
Subscribers: fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D40012
llvm-svn: 319538
|
|
|
|
|
|
| |
This is a superset of the tests proposed with D40012 to show another potential improvement.
llvm-svn: 319041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'ord' and 'uno' predicates have a logic operation for NAN built into their definitions:
FCMP_ORD = 7, ///< 0 1 1 1 True if ordered (no nans)
FCMP_UNO = 8, ///< 1 0 0 0 True if unordered: isnan(X) | isnan(Y)
So we can simplify patterns like this:
(fcmp ord (known NNAN), X) && (fcmp ord X, Y) --> fcmp ord X, Y
(fcmp uno (known NNAN), X) || (fcmp uno X, Y) --> fcmp uno X, Y
It might be better to split this into (X uno 0) | (Y uno 0) as a canonicalization, but that
would be another patch.
Differential Revision: https://reviews.llvm.org/D40130
llvm-svn: 318627
|
|
|
|
| |
llvm-svn: 318408
|
|
|
|
|
|
|
|
| |
(PR34838)
Poison allows us to return a better result than undef.
llvm-svn: 315595
|
|
|
|
| |
llvm-svn: 315152
|
|
|
|
|
|
|
|
|
|
|
|
| |
Call ConstantFoldSelectInstruction() to fold cases like below
select <2 x i1><i1 true, i1 false>, <2 x i8> <i8 0, i8 1>, <2 x i8> <i8 2, i8 3>
All operands are constants and the condition has mixed true and false conditions.
Differential Revision: https://reviews.llvm.org/D38369
llvm-svn: 314741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should bring signed div/rem analysis up to the same level as unsigned.
We use icmp simplification to determine when the divisor is known greater than the dividend.
Each positive test is followed by a negative test to show that we're not overstepping the boundaries of the known bits.
There are extra tests for the signed-min-value special cases.
Alive proofs:
http://rise4fun.com/Alive/WI5
Differential Revision: https://reviews.llvm.org/D37713
llvm-svn: 313264
|
|
|
|
| |
llvm-svn: 313161
|
|
|
|
|
|
| |
Too much division...the quotient is the answer.
llvm-svn: 312943
|
|
|
|
|
|
|
|
|
|
| |
As noted in PR34517, the handling of signed div/rem is not on par with
unsigned div/rem. Signed is harder to reason about, but it should be
possible to handle at least some of these using the same technique that
we use for unsigned: use icmp logic to see if there's a relationship
between the quotient and divisor.
llvm-svn: 312938
|
|
|
|
|
|
|
|
|
| |
This removes some duplicated code and makes it easier to support signed div/rem
in a similar way if we want to do that. Note that the existing comments were not
accurate - we don't need a constant divisor to simplify; icmp simplification does
more than that. But as the added tests show, it could go even further.
llvm-svn: 312885
|
|
|
|
| |
llvm-svn: 312685
|
|
|
|
| |
llvm-svn: 312413
|
|
|
|
|
|
| |
These are all tests that result in a constant, so moving the tests over to where they are actually handled.
llvm-svn: 312411
|
|
|
|
|
|
|
|
|
|
| |
This code is double-dead:
1. We simplify all selects with constant true/false condition in InstSimplify.
I've minimized/moved the tests to show that works as expected.
2. All remaining vector selects with a constant condition are canonicalized to
shufflevector, so we really can't see this pattern.
llvm-svn: 312123
|
|
|
|
|
|
|
|
| |
This adds support non-canonical compare predicates. InstSimplify can't rely on canonicalization to have occurred.
Differential Revision: https://reviews.llvm.org/D36646
llvm-svn: 310893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
decomposeBitTestICmp and use it in the InstSimplify"
This recommits r310869, with the moved files and no extra changes.
Original commit message:
This addresses a fixme in InstSimplify about using decomposeBitTest. This also fixes InstSimplify to handle ugt and ult compares too.
I've modified the interface a little to return only the APInt version of the mask that InstSimplify needs. InstCombine now has a small wrapper routine to create a Constant out of it. I've also dropped the returning of 0 since InstSimplify doesn't need that. So InstCombine creates a zero constant itself.
I also had to make decomposeBitTest support vectors since InstSimplify needs that.
As InstSimplify can't use something from the Transforms library, I've moved the CmpInstAnalysis code to the Analysis library.
Differential Revision: https://reviews.llvm.org/D36593
llvm-svn: 310889
|
|
|
|
|
|
|
|
| |
decomposeBitTestICmp and use it in the InstSimplify"
Failed to add the two files that moved. And then added an extra change I didn't mean to while trying to fix that. Reverting everything.
llvm-svn: 310873
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use it in the InstSimplify
This addresses a fixme in InstSimplify about using decomposeBitTest. This also fixes InstSimplify to handle ugt and ult compares too.
I've modified the interface a little to return only the APInt version of the mask that InstSimplify needs. InstCombine now has a small wrapper routine to create a Constant out of it. I've also dropped the returning of 0 since InstSimplify doesn't need that. So InstCombine creates a zero constant itself.
I also had to make decomposeBitTest support vectors since InstSimplify needs that.
As InstSimplify can't use something from the Transforms library, I've moved the CmpInstAnalysis code to the Analysis library.
Differential Revision: https://reviews.llvm.org/D36593
llvm-svn: 310869
|
|
|
|
|
|
| |
ugt/ult/uge/ule compares. NFC
llvm-svn: 310868
|
|
|
|
|
|
| |
doesn't work with non-canonical comparisons.
llvm-svn: 310542
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in ConstantFoldGetElementPtr() assumes integers, and
therefore it crashes trying to get the integer bidwith of a vector
type (in this case <4 x i32>. I just changed the code to prevent
the folding in case of vectors and I didn't bother to generalize
as this doesn't seem to me something that really happens in
practice, but I'm willing to change the patch if you think
it's worth it.
This is hard to trigger from -instsimplify or -instcombine
only as the second instruction is dead, so the test uses loop-unroll.
Differential Revision: https://reviews.llvm.org/D35956
llvm-svn: 309330
|
|
|
|
| |
llvm-svn: 304784
|
|
|
|
|
|
| |
intrinsic. The second argument is not a vector so needs special treatment.
llvm-svn: 304679
|
|
|
|
|
|
| |
vector llvm.powi intrinsics due to the second argument not being a vector.
llvm-svn: 304678
|
|
|
|
|
|
| |
to understand that the second argument is still a scalar.
llvm-svn: 304668
|
|
|
|
|
|
| |
some showing missed optimizations. NFC
llvm-svn: 304667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
null, (inttoptr x) as well as it handles icmp (inttoptr x), null
Summary:
The constant folding code currently assumes that the constant expression will always be on the left and the simple null will be on the right. But that's not true at least on the path from InstSimplify.
This patch adds support to ConstantFolding to detect the reversed case.
Reviewers: spatel, dberlin, majnemer, davide, joey
Reviewed By: joey
Subscribers: joey, llvm-commits
Differential Revision: https://reviews.llvm.org/D33801
llvm-svn: 304559
|
|
|
|
|
|
| |
(icmp eq null, inttoptr x) when the null is on the left hand side. NFC
llvm-svn: 304474
|
|
|
|
|
|
|
|
|
|
| |
C2) handling in order to support splat vectors.
The tests here are have operands commuted to provide more coverage. I also commuted one of the instructions in the scalar tests so the 4 tests cover the 4 commuted variations
Differential Revision: https://reviews.llvm.org/D33599
llvm-svn: 304021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the Zero or Undef is on the LHS.
Summary: This code was migrated from InstCombine a few years ago. InstCombine had nearby code that would move Constants to the RHS for these, but InstSimplify doesn't have such code on this path.
Reviewers: spatel, majnemer, davide
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33473
llvm-svn: 303774
|
|
|
|
|
|
| |
add/sub/mul with overflow intrinsics. NFC
llvm-svn: 303671
|
|
|
|
| |
llvm-svn: 303664
|
|
|
|
|
|
|
|
| |
Currently m_Not only works the canonical xor X, -1 form that InstCombine produces. InstSimplify can't rely on this canonicalization.
Differential Revision: https://reviews.llvm.org/D33331
llvm-svn: 303379
|
|
|
|
| |
llvm-svn: 303367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already handled all of the new tests identically, but several
of those went through a lot of unnecessary processing before
getting folded.
Another motivation for grouping these cases together is that
InstCombine needs a similar fold. Currently, it handles the
'not' cases inefficiently which can lead to bugs as described
in the post-commit comments of:
https://reviews.llvm.org/D32143
llvm-svn: 303295
|