summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstSimplify
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstSimplify] vector div/rem with any zero element in divisor is undefSanjay Patel2017-03-092-10/+6
| | | | | | | | | | | This was suggested as a DAG simplification in the review for rL297026 : http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170306/435253.html ...but let's start with IR since we have actual docs for IR (LangRef). Differential Revision: https://reviews.llvm.org/D30665 llvm-svn: 297390
* [InstSimplify] add tests for vector div/rem with UB potential; NFCSanjay Patel2017-03-062-0/+84
| | | | llvm-svn: 297048
* [InstSimplify] regenerate checks; NFCSanjay Patel2017-03-062-16/+16
| | | | llvm-svn: 297040
* [InstSimplify] add nsw/nuw (xor X, signbit), signbit --> XSanjay Patel2017-02-181-6/+2
| | | | | | | | | The change to InstCombine in: https://reviews.llvm.org/D29729 ...exposes this missing fold in InstSimplify, so adding this first to avoid a regression. llvm-svn: 295573
* [InstSimplify] add tests for add nsw/nuw (xor X, signbit), signbit --> X; NFCSanjay Patel2017-02-181-0/+26
| | | | llvm-svn: 295572
* [ValueTracking] emit a remark when we detect a conflicting assumption (PR31809)Sanjay Patel2017-02-061-5/+28
| | | | | | | | | | | | This is a follow-up to D29395 where we try to be good citizens and let the user know that we've probably gone off the rails. This should allow us to resolve: https://llvm.org/bugs/show_bug.cgi?id=31809 Differential Revision: https://reviews.llvm.org/D29404 llvm-svn: 294208
* [ValueTracking] remove a FIXME for something we don't want to do; NFCSanjay Patel2017-02-011-2/+1
| | | | | | | | The comment was added with: https://reviews.llvm.org/rL293773 ...but there would be a cost to implement this and possibly no payoff. llvm-svn: 293823
* [ValueTracking] avoid crashing from bad assumptions (PR31809)Sanjay Patel2017-02-011-0/+36
| | | | | | | | | | | | | A program may contain llvm.assume info that disagrees with other analysis. This may be caused by UB in the program, so we must not crash because of that. As noted in the code comments: https://llvm.org/bugs/show_bug.cgi?id=31809 ...we can do better, but this at least avoids the assert/crash in the bug report. Differential Revision: https://reviews.llvm.org/D29395 llvm-svn: 293773
* [ValueTracking] Implement SignBitMustBeZero correctly for sqrt.Justin Lebar2017-01-261-0/+54
| | | | | | | | | | | | | | Summary: Previously we assumed that the result of sqrt(x) always had 0 as its sign bit. But sqrt(-0) == -0. Reviewers: hfinkel, efriedma, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28928 llvm-svn: 293115
* [InstSimplify] try to eliminate icmp Pred (add nsw X, C1), C2Sanjay Patel2017-01-241-21/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was surprised to see that we're missing icmp folds based on 'add nsw' in InstCombine, but we should handle the InstSimplify cases first because that could make the InstCombine code simpler. Here are Alive-based proofs for the logic: Name: add_neg_constant Pre: C1 < 0 && (C2 > ((1<<(width(C1)-1)) + C1)) %a = add nsw i7 %x, C1 %b = icmp sgt %a, C2 => %b = false Name: add_pos_constant Pre: C1 > 0 && (C2 < ((1<<(width(C1)-1)) + C1 - 1)) %a = add nsw i6 %x, C1 %b = icmp slt %a, C2 => %b = false Name: nuw Pre: C1 u>= C2 %a = add nuw i11 %x, C1 %b = icmp ult %a, C2 => %b = false Differential Revision: https://reviews.llvm.org/D29053 llvm-svn: 292952
* [InstSimplify] add tests to show missing folds from 'icmp (add nsw)'; NFCSanjay Patel2017-01-231-0/+169
| | | | llvm-svn: 292841
* [ValueTracking] Extend known bits to understand @llvm.bitreverse.Chad Rosier2017-01-171-0/+31
| | | | | | Differential Revision: https://reviews.llvm.org/D28780 llvm-svn: 292233
* [InstCombine / InstSimplify] add and move tests for lshr transforms; NFCSanjay Patel2017-01-131-0/+43
| | | | llvm-svn: 291970
* [InstCombine] if the condition of a select may be known via assumes, ↵Sanjay Patel2017-01-131-1/+2
| | | | | | | | | | | | | | | | | | | | eliminate the select This is a limited solution for PR31512: https://llvm.org/bugs/show_bug.cgi?id=31512 The motivation is that we will need to increase usage of llvm.assume and/or metadata to solve PR28430: https://llvm.org/bugs/show_bug.cgi?id=28430 ...and this kind of simplification is needed to take advantage of that extra information. The 'not' test case would be handled by: https://reviews.llvm.org/D28485 Differential Revision: https://reviews.llvm.org/D28337 llvm-svn: 291915
* InstSimplify: Eliminate fabs on known positiveMatt Arsenault2017-01-111-0/+92
| | | | llvm-svn: 291624
* [InstSimplify] Optimize away udivs in the presence of range metadataDavid Majnemer2017-01-061-0/+15
| | | | | | We know that udiv %V, C can be optimized away to 0 if %V is ult C. llvm-svn: 291296
* [InstSimplify] Optimize away urems in the presence of range metadataDavid Majnemer2017-01-061-0/+14
| | | | | | We know that urem %V, C can be optimized away to %V if %V is ult C. llvm-svn: 291282
* [InstSimplify] add tests to show missing select simplifications; NFCSanjay Patel2017-01-051-0/+28
| | | | llvm-svn: 291043
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-1/+1
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* Make processing @llvm.assume more efficient by using operand bundlesHal Finkel2016-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | There was an efficiency problem with how we processed @llvm.assume in ValueTracking (and other places). The AssumptionCache tracked all of the assumptions in a given function. In order to find assumptions relevant to computing known bits, etc. we searched every assumption in the function. For ValueTracking, that means that we did O(#assumes * #values) work in InstCombine and other passes (with a constant factor that can be quite large because we'd repeat this search at every level of recursion of the analysis). Several of us discussed this situation at the last developers' meeting, and this implements the discussed solution: Make the values that an assume might affect operands of the assume itself. To avoid exposing this detail to frontends and passes that need not worry about it, I've used the new operand-bundle feature to add these extra call "operands" in a way that does not affect the intrinsic's signature. I think this solution is relatively clean. InstCombine adds these extra operands based on what ValueTracking, LVI, etc. will need and then those passes need only search the users of the values under consideration. This should fix the computational-complexity problem. At this point, no passes depend on the AssumptionCache, and so I'll remove that as a follow-up change. Differential Revision: https://reviews.llvm.org/D27259 llvm-svn: 289755
* [Constants] don't die processing non-ConstantInt GEP indices in ↵Sanjay Patel2016-12-111-0/+11
| | | | | | | | | isGEPWithNoNotionalOverIndexing() (PR31262) This should fix: https://llvm.org/bugs/show_bug.cgi?id=31262 llvm-svn: 289401
* [InstSimplify] Add "X / 1.0" to SimplifyFDivInst.Zia Ansari2016-12-081-3/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D27587 llvm-svn: 289153
* [InstSimplify] add fdiv x/1.0 test and update checks; NFCSanjay Patel2016-12-081-8/+25
| | | | llvm-svn: 289098
* [InstSimplify] fixed (?) to not mutate icmpsSanjay Patel2016-12-062-0/+52
| | | | | | | | | | | | | | As Eli noted in the post-commit thread for r288833, the use of swapOperands() may not be allowed in InstSimplify, so I'm removing those calls here pending further review. The swap mutates the icmp, and there doesn't appear to be precedent for instruction mutation in InstSimplify. I didn't actually have any tests for those cases, so I'm adding a few here. llvm-svn: 288855
* [InstSimplify] add folds for and-of-icmps with same operandsSanjay Patel2016-12-061-197/+58
| | | | | | | | | | | All of these (and a few more) are already handled by InstCombine, but we shouldn't have to wait until then to simplify these because they're cheap to deal with here in InstSimplify. This is the 'and' sibling of the earlier 'or' patch: https://reviews.llvm.org/rL288833 llvm-svn: 288841
* [InstSimplify] add tests for and-of-icmps; NFCSanjay Patel2016-12-061-0/+1352
| | | | llvm-svn: 288837
* [InstSimplify] add folds for or-of-icmps with same operandsSanjay Patel2016-12-061-198/+59
| | | | | | | | All of these (and a few more) are already handled by InstCombine, but we shouldn't have to wait until then to simplify these because they're cheap to deal with here in InstSimplify. llvm-svn: 288833
* [InstSimplify] add tests for or-of-icmps; NFCSanjay Patel2016-12-061-0/+1352
| | | | llvm-svn: 288830
* Simplify `x >=u x >> y` and `x >=u x udiv y`Sanjoy Das2016-10-261-0/+32
| | | | | | | | | | | | | | | | | | | Summary: Extends InstSimplify to handle both `x >=u x >> y` and `x >=u x udiv y`. This is a folloup of rL258422 and https://github.com/rust-lang/rust/pull/30917 where llvm failed to optimize away the bounds checking in a binary search. Patch by Arthur Silva! Reviewers: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25941 llvm-svn: 285228
* [InstSimplify] fold negation of sign-bitSanjay Patel2016-10-191-10/+4
| | | | | | | | | | | | | | | | 0 - X --> X, if X is 0 or the minimum signed value 0 - X --> 0, if X is 0 or the minimum signed value and the sub is NSW I noticed this pattern might be created in the backend after the change from D25485, so we'll want to add a similar fold for the DAG. The use of computeKnownBits in InstSimplify may be something to investigate if the compile time of InstSimplify is noticeable. We could replace computeKnownBits with specific pattern matchers or limit the recursion. Differential Revision: https://reviews.llvm.org/D25785 llvm-svn: 284649
* [InstSimplify] move one and add more tests for potential negation foldsSanjay Patel2016-10-192-9/+63
| | | | llvm-svn: 284627
* [InstSimplify] allow or-of-icmps folds with vector splat constantsSanjay Patel2016-09-281-32/+6
| | | | llvm-svn: 282592
* [InstSimplify] add vector splat tests for or-of-icmpsSanjay Patel2016-09-281-0/+92
| | | | llvm-svn: 282591
* [InstSimplify] allow and-of-icmps folds with vector splat constantsSanjay Patel2016-09-281-0/+66
| | | | llvm-svn: 282590
* [ConstantFold] Improve the bitcast folding logic for constant vectors.Andrea Di Biagio2016-09-131-18/+18
| | | | | | | | | | | | | | | | | | | | The constant folder didn't know how to always fold bitcasts of constant integer vectors. In particular, it was unable to handle the case where a constant vector had some undef elements, and the resulting (i.e. bitcasted) vector type had more elements than the original vector type. Example: %cast = bitcast <2 x i64><i64 undef, i64 2> to <4 x i32> On a little endian target, %cast could have been folded to: <4 x i32><i32 undef, i32 undef, i32 2, i32 0> This patch improves the folding logic by teaching how to correctly propagate undef elements in the folded vector. Differential Revision: https://reviews.llvm.org/D24301 llvm-svn: 281343
* [InstSimplify] Add tests to show missed bitcast folding opportunities.Andrea Di Biagio2016-09-131-0/+144
| | | | | | | | | | InstSimplify doesn't always know how to fold a bitcast of a constant vector. In particular, the logic in InstSimplify doesn't know how to handle the case where the constant vector in input contains some undef elements, and the number of elements is smaller than the number of elements of the bitcast vector type. llvm-svn: 281332
* Add unittest for r280760Dehao Chen2016-09-081-0/+31
| | | | llvm-svn: 280963
* Regenerate vector bitcast folding tests using update_test_checks.py.Andrea Di Biagio2016-09-071-0/+125
| | | | | | | Two tests have been merged together, regenerated and then moved to a more appropriate directory. No functional change. llvm-svn: 280814
* [instsimplify] Fix incorrect folding of an ordered fcmp with a vector of all ↵Andrea Di Biagio2016-09-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | NaN. This patch fixes a crash caused by an incorrect folding of an ordered comparison between a packed floating point vector and a splat vector of NaN. An ordered comparison between a vector and a constant vector of NaN, should always be folded into a constant vector where each element is i1 false. Since revision 266175, SimplifyFCmpInst folds the ordered fcmp into a scalar 'false'. Later on, this would cause an assertion failure, since the value type of the folded value doesn't match the expected value type of the uses of the original instruction: "Assertion failed: New->getType() == getType() && "replaceAllUses of value with new value of different type!". This patch fixes the issue and adds a test case to the already existing test InstSimplify/floating-point-compares.ll. Differential Revision: https://reviews.llvm.org/D24143 llvm-svn: 280488
* [InstCombine] replace divide-by-constant checks with asserts; NFCSanjay Patel2016-08-301-1/+16
| | | | | | | These folds already have tests for scalar and vector types, except for the vector div-by-0 case, so I'm adding tests for that. llvm-svn: 280115
* [InstSimplify] allow icmp with constant folds for splat vectors, part 2Sanjay Patel2016-08-231-60/+20
| | | | | | | | | | | | Completes the m_APInt changes for simplifyICmpWithConstant(). Other commits in this series: https://reviews.llvm.org/rL279492 https://reviews.llvm.org/rL279530 https://reviews.llvm.org/rL279534 https://reviews.llvm.org/rL279538 llvm-svn: 279543
* [InstSimplify] allow icmp with constant folds for splat vectors, part 1Sanjay Patel2016-08-231-4/+2
| | | | llvm-svn: 279538
* [InstSimplify] add tests to show missing vector icmp foldsSanjay Patel2016-08-231-0/+238
| | | | llvm-svn: 279534
* [InstSimplify] move icmp with constant tests to another file; NFCSanjay Patel2016-08-232-165/+222
| | | | | | | | | | | ...because like the corresponding code, this is just too big to keep adding to. And the next step is to add a vector version of each of these tests to show missed folds. Also, auto-generate CHECK lines and add comments for the tests that correspond to the source code. llvm-svn: 279530
* [InstSimplify] Fold gep (gep V, C), (xor V, -1) to C-1David Majnemer2016-08-162-13/+27
| | | | llvm-svn: 278779
* [InstSimplify] Fold gep (gep V, C), (sub 0, V) to CDavid Majnemer2016-08-071-0/+13
| | | | llvm-svn: 277952
* [InstSimplify] Try hard to simplify pointer comparisonsDavid Majnemer2016-08-071-0/+13
| | | | | | | Simplify ptrtoint comparisons involving operands with different source types. llvm-svn: 277951
* remove FIXME comments (fixed with r277738)Sanjay Patel2016-08-041-2/+0
| | | | llvm-svn: 277744
* [InstCombine] use m_APInt to allow icmp eq (op X, Y), C folds for splat ↵Sanjay Patel2016-08-041-6/+3
| | | | | | | | | constant vectors I'm removing a misplaced pair of more specific folds from InstCombine in this patch as well, so we know where those folds are happening in InstSimplify. llvm-svn: 277738
* add tests for missing vector foldsSanjay Patel2016-08-041-6/+30
| | | | llvm-svn: 277736
OpenPOWER on IntegriCloud