summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstSimplify
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstSimplify][NFC] Tests for skipping 'div-by-0' checks before ↵Roman Lebedev2019-07-222-0/+188
| | | | | | | | | @llvm.umul.with.overflow These may remain after @llvm.umul.with.overflow was canonicalized from the code that was originally doing the check via division. llvm-svn: 366751
* [InstructionSimplify] Apply sext/trunc after pointer strippingMichael Liao2019-07-161-1/+10
| | | | | | | | | | | | | | | | | Summary: - As the pointer stripping could trace through `addrspacecast` now, need to sext/trunc the offset to ensure it has the same width as the pointer after stripping. Reviewers: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64768 llvm-svn: 366162
* [NFC] Revisited tests for D64285David Bolvansky2019-07-111-379/+0
| | | | llvm-svn: 365815
* [NFC] Updated tests for D64285David Bolvansky2019-07-111-32/+107
| | | | llvm-svn: 365765
* [NFC] Fixed testsDavid Bolvansky2019-07-091-69/+133
| | | | llvm-svn: 365506
* [NFC] Added tests for D64285David Bolvansky2019-07-091-0/+240
| | | | llvm-svn: 365501
* [InstSimplify] simplify power-of-2 (single bit set) sequencesSanjay Patel2019-06-201-8/+2
| | | | | | | | | | | | | | | | | | | | As discussed in PR42314: https://bugs.llvm.org/show_bug.cgi?id=42314 Improving the canonicalization for these patterns: rL363956 ...means we should adjust/enhance the related simplification. https://rise4fun.com/Alive/w1cp Name: isPow2 or zero %x = and i32 %xx, 2048 %a = add i32 %x, -1 %r = and i32 %a, %x => %r = i32 0 llvm-svn: 363997
* [InstSimplify] add tests for known-not-a-power-of-2; NFCSanjay Patel2019-06-201-0/+28
| | | | | | | | | | | | | | I added a canonicalization to create this general pattern in: rL363956 But as noted in PR42314: https://bugs.llvm.org/show_bug.cgi?id=42314#c11 ...we have a (potentially expensive) simplification for the version of the code that we just canonicalized away from, so we should add/adjust that code to match. llvm-svn: 363981
* [InstSimplify] add a phi test with 1 incoming value; NFCSanjay Patel2019-06-191-2/+32
| | | | | | | D63489 proposes to change this behavior, but there's no direct -instsimplify test to verify that the transform exists. llvm-svn: 363842
* [ConstantFolding] Fix assertion failure on non-power-of-two vector load.Jay Foad2019-06-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The test case does an (out of bounds) load from a global constant with type <3 x float>. InstSimplify tried to turn this into an integer load of the whole alloc size of the vector, which is 128 bits due to alignment padding, and then bitcast this to <3 x vector> which failed an assertion due to the type size mismatch. The fix is to do an integer load of the normal size of the vector, with no alignment padding. Reviewers: tpr, arsenm, majnemer, dstuttard Reviewed By: arsenm Subscribers: hfinkel, wdng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63375 llvm-svn: 363784
* [InstSimplify] Fix addo/subo undef folds (PR42209)Roman Lebedev2019-06-161-8/+8
| | | | | | | | | | | | | | | | Fix folds of addo and subo with an undef operand to be: `@llvm.{u,s}{add,sub}.with.overflow` all fold to `{ undef, false }`, as per LLVM undef rules. Same for commuted variants. Based on the original version of the patch by @nikic. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=42209 | PR42209 ]] Differential Revision: https://reviews.llvm.org/D63065 llvm-svn: 363522
* [InstSimplify] enhance fcmp fold with never-nan operandSanjay Patel2019-06-091-12/+4
| | | | | | | | | | | | | | | | This is another step towards correcting our usage of fast-math-flags when applied on an fcmp. In this case, we are checking for 'nnan' on the fcmp itself rather than the operand of the fcmp. But I'm leaving that clause in until we're more confident that we can stop relying on fcmp's FMF. By using the more general "isKnownNeverNaN()", we gain a simplification shown on the tests with 'uitofp' regardless of the FMF on the fcmp (uitofp never produces a NaN). On the tests with 'fabs', we are now relying on the FMF for the call fabs instruction in addition to the FMF on the fcmp. This is a continuation of D62979 / rL362879. llvm-svn: 362903
* [InstSimplify] add tests for fcmp with known-never-nan operands; NFCSanjay Patel2019-06-091-2/+48
| | | | | | Opposite predicate for rL362742 / rL362879 / D62979 llvm-svn: 362902
* [InstSimplify] enhance fcmp fold with never-nan operandSanjay Patel2019-06-081-12/+4
| | | | | | | | | | | | | | | | | | This is 1 step towards correcting our usage of fast-math-flags when applied on an fcmp. In this case, we are checking for 'nnan' on the fcmp itself rather than the operand of the fcmp. But I'm leaving that clause in until we're more confident that we can stop relying on fcmp's FMF. By using the more general "isKnownNeverNaN()", we gain a simplification shown on the tests with 'uitofp' regardless of the FMF on the fcmp (uitofp never produces a NaN). On the tests with 'fabs', we are now relying on the FMF for the call fabs instruction in addition to the FMF on the fcmp. I'll update the 'ult' case below here as a follow-up assuming no problems here. Differential Revision: https://reviews.llvm.org/D62979 llvm-svn: 362879
* [InstSimplify] add tests for fcmp with known-never-nan operands; NFCSanjay Patel2019-06-061-2/+46
| | | | llvm-svn: 362742
* [InstSimplify] fold insertelement-of-extractelementSanjay Patel2019-05-241-6/+2
| | | | | | | | This was partly handled in InstCombine (only the constant index case), so delete that and zap it more generally in InstSimplify. llvm-svn: 361576
* [InstSimplify] add tests for insert-of-extract; NFCSanjay Patel2019-05-241-0/+22
| | | | llvm-svn: 361575
* [InstSimplify] insertelement V, undef, ? --> VSanjay Patel2019-05-231-5/+25
| | | | | | | | This was part of InstCombine, but it's better placed in InstSimplify. InstCombine also had an unreachable but weaker fold for insertelement with undef index, so that is deleted. llvm-svn: 361559
* [InstSimplify] Teach fsub -0.0, (fneg X) ==> X about unary fnegCameron McInally2019-05-201-9/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D62077 llvm-svn: 361151
* [InstSimplify] fold fcmp (maxnum, X, C1), C2Sanjay Patel2019-05-191-37/+13
| | | | | | | | | | | | | This is the sibling transform for rL360899 (D61691): maxnum(X, GreaterC) == C --> false maxnum(X, GreaterC) <= C --> false maxnum(X, GreaterC) < C --> false maxnum(X, GreaterC) >= C --> true maxnum(X, GreaterC) > C --> true maxnum(X, GreaterC) != C --> true llvm-svn: 361118
* [NFC][InstSimplify] Add more unary fneg tests to floating-point-arithmetic.llCameron McInally2019-05-171-0/+29
| | | | llvm-svn: 361076
* [NFC][InstSimplify] Precommit new unary fneg testCameron McInally2019-05-172-2/+49
| | | | llvm-svn: 361060
* [NFC][InstSImplify] Fix flip-flopped comments and test namesCameron McInally2019-05-171-6/+6
| | | | | | | | In test/Transforms/InstSimplify/floating-point-arithmetic.ll Differential Revision: https://reviews.llvm.org/D62069 llvm-svn: 361057
* [InstSimplify] Add unary fneg to `fsub 0.0, (fneg X) ==> X` transformCameron McInally2019-05-171-6/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D62013 llvm-svn: 361047
* [NFC][InstSimplify] Update fast-math.ll tests I botched in r360808.Cameron McInally2019-05-161-8/+8
| | | | | | These were new tests I added in r360808. I made a mistake while converting the exisiting binary FNeg test into the new unary FNeg tests. Correct that. llvm-svn: 360928
* [InstSimplify] add tests for fcmp of maxnum with constants; NFCSanjay Patel2019-05-161-0/+198
| | | | | | Sibling tests for rL360899 (D61691). llvm-svn: 360905
* [InstSimplify] fold fcmp (minnum, X, C1), C2Sanjay Patel2019-05-161-35/+52
| | | | | | | | | | | | | | | | | | | | | minnum(X, LesserC) == C --> false minnum(X, LesserC) >= C --> false minnum(X, LesserC) > C --> false minnum(X, LesserC) != C --> true minnum(X, LesserC) <= C --> true minnum(X, LesserC) < C --> true maxnum siblings will follow if there are no problems here. We should be able to perform some other combines when the constants are equal or greater-than too, but that would go in instcombine. We might also generalize this by creating an FP ConstantRange (similar to what we do for integers). Differential Revision: https://reviews.llvm.org/D61691 llvm-svn: 360899
* Revert llvm-svn: 360807Cameron McInally2019-05-151-16/+0
| | | | | | Somehow submitted this patch twice. llvm-svn: 360812
* Pre-commit unary fneg tests to InstSimplifyCameron McInally2019-05-151-4/+49
| | | | llvm-svn: 360808
* Add unary fneg to InstSimplify/fp-nan.llCameron McInally2019-05-151-0/+16
| | | | llvm-svn: 360807
* Add unary fneg to InstSimplify/fp-nan.llCameron McInally2019-05-151-0/+16
| | | | llvm-svn: 360797
* Teach InstSimplify -X + X --> 0.0 about unary FNegCameron McInally2019-05-151-4/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D61916 llvm-svn: 360777
* [InstSimplify] add tests for fcmp+minnum; NFCSanjay Patel2019-05-081-0/+157
| | | | llvm-svn: 360275
* Revert "[ValueTracking] Improve isKnowNonZero for Ints"Nikita Popov2019-05-081-3/+7
| | | | | | | | | This reverts commit 3b137a495686bd6018d115ea82fb8bb7718349fd. As reported in https://reviews.llvm.org/D60846, this is causing miscompiles. llvm-svn: 360260
* [ValueTracking] Improve isKnowNonZero for IntsDan Robertson2019-05-081-7/+3
| | | | | | | | | Improve isKnownNonZero for integers in order to improve cttz optimizations. Differential Revision: https://reviews.llvm.org/D60846 llvm-svn: 360222
* [ValueTracking] add logic for known-never-nan with minnum/maxnumSanjay Patel2019-05-071-6/+2
| | | | | | From the LangRef: "Returns NaN only if both operands are NaN." llvm-svn: 360206
* [InstSimplify] add tests for minnum/maxnum and NaN; NFCSanjay Patel2019-05-071-0/+22
| | | | llvm-svn: 360197
* Add FNeg support to InstructionSimplifyCameron McInally2019-05-061-0/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D61573 llvm-svn: 360053
* [NFC] Add baseline tests for int isKnownNonZeroDan Robertson2019-04-261-0/+104
| | | | | | | | Add baseline tests for improvements of isKnownNonZero for integer types. Differential Revision: https://reviews.llvm.org/D60932 llvm-svn: 359267
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-1789-0/+26031
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-1789-26031/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [ConstantFold] Don't evaluate FP or FP vector casts or truncations when ↵Fangrui Song2019-04-121-0/+8
| | | | | | | | simplifying icmp Fix PR41476 llvm-svn: 358262
* Reapply [ValueTracking] Support min/max selects in computeConstantRange()Nikita Popov2019-04-071-16/+4
| | | | | | | | | | | | | | | | | | Add support for min/max flavor selects in computeConstantRange(), which allows us to fold comparisons of a min/max against a constant in InstSimplify. This fixes an infinite InstCombine loop, with the test case taken from D59378. Relative to the previous iteration, this contains some adjustments for AMDGPU med3 tests: The AMDGPU target runs InstSimplify prior to codegen, which ends up constant folding some existing med3 tests after this change. To preserve these tests a hidden -amdgpu-scalar-ir-passes option is added, which allows disabling scalar IR passes (that use InstSimplify) for testing purposes. Differential Revision: https://reviews.llvm.org/D59506 llvm-svn: 357870
* InstSimplify: Fold round intrinsics from sitofp/uitofpMatt Arsenault2019-04-031-24/+12
| | | | | | https://godbolt.org/z/gEMRZb llvm-svn: 357549
* InstSimplify: Add missing case from r357386Matt Arsenault2019-04-021-0/+23
| | | | llvm-svn: 357443
* InstSimplify: Add baseline test for upcoming changeMatt Arsenault2019-04-011-0/+120
| | | | llvm-svn: 357386
* [InstSimplify] Add tests for signed icmp of and/or; NFCNikita Popov2019-03-211-6/+150
| | | | | | | Even if a signed predicate is used, the ranges computed for and/or are unsigned, resulting in missed simplifications. llvm-svn: 356720
* [ValueTracking] Compute range for abs without nswNikita Popov2019-03-201-5/+1
| | | | | | | | | | | | | This is a small followup to D59511. The code that was moved into computeConstantRange() there is a bit overly conversative: If the abs is not nsw, it does not compute any range. However, abs without nsw still has a well-defined contiguous unsigned range from 0 to SIGNED_MIN. This is a lot less useful than the usual 0 to SIGNED_MAX range, but if we're already here we might as well specify it... Differential Revision: https://reviews.llvm.org/D59563 llvm-svn: 356586
* [InstSimplify] Add additional cmp of abs without nsw tests; NFCNikita Popov2019-03-191-0/+31
| | | | llvm-svn: 356520
* Revert "[ValueTracking][InstSimplify] Support min/max selects in ↵Nikita Popov2019-03-181-4/+16
| | | | | | | | | | computeConstantRange()" This reverts commit 106f0cdefb02afc3064268dc7a71419b409ed2f3. This change impacts the AMDGPU smed3.ll and umed3.ll codegen tests. llvm-svn: 356424
OpenPOWER on IntegriCloud