summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstSimplify
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstSimplify, InstCombine] add/update tests with FP +0.0 vector with undef; NFCSanjay Patel2018-03-252-4/+40
| | | | llvm-svn: 328455
* [InstSimplify] regenerate checks, move tests; NFCSanjay Patel2018-03-231-18/+43
| | | | llvm-svn: 328327
* [InstSimplify] fp_binop X, NaN --> NaNSanjay Patel2018-03-211-40/+20
| | | | | | | | We propagate the existing NaN value when possible. Differential Revision: https://reviews.llvm.org/D44521 llvm-svn: 328140
* [InstSimplify] loosen FMF for sqrt(X) * sqrt(X) --> XSanjay Patel2018-03-181-2/+37
| | | | | | | | | As shown in the code comment, we don't need all of 'fast', but we do need reassoc + nsz + nnan. Differential Revision: https://reviews.llvm.org/D43765 llvm-svn: 327796
* [InstSimplify] add NaN constant diversity; NFCSanjay Patel2018-03-161-39/+75
| | | | llvm-svn: 327743
* [InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682)Roman Lebedev2018-03-151-63/+18
| | | | | | | | | | | | | | | | | | | This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
* [ConstantFolding, InstSimplify] Handle more vector GEPsMatthew Simpson2018-03-151-0/+18
| | | | | | | | | | This patch addresses some additional cases where the compiler crashes upon encountering vector GEPs. This should fix PR36116. Differential Revision: https://reviews.llvm.org/D44219 Reference: https://bugs.llvm.org/show_bug.cgi?id=36116 llvm-svn: 327638
* [InstSimplify] add tests with NaN operand for fp binops; NFCSanjay Patel2018-03-151-0/+185
| | | | llvm-svn: 327631
* [PatternMatch, InstSimplify] allow undef elements when matching any vector ↵Sanjay Patel2018-03-151-13/+5
| | | | | | | | | | | FP zero This matcher implementation appears to be slightly more efficient than the generic constant check that it is replacing because every use was for matching FP patterns, but the previous code would check int and pointer type nulls too. llvm-svn: 327627
* [InstSimplify] remove 'nsz' requirement for frem 0, XSanjay Patel2018-03-151-6/+3
| | | | | | | | | | | From the LangRef definition for frem: "The value produced is the floating-point remainder of the two operands. This is the same output as a libm ‘fmod‘ function, but without any possibility of setting errno. The remainder has the same sign as the dividend. This instruction is assumed to execute in the default floating-point environment." llvm-svn: 327626
* [InstSimplify] add tests for frem and vectors with undef; NFCSanjay Patel2018-03-141-3/+88
| | | | | | | | | These should all be folded. The vector tests need to have m_AnyZero updated to ignore undef elements, but we need to be careful not to return the existing value in that case and unintentionally propagate undef. llvm-svn: 327585
* [InstSimplify] fix folds for (0.0 - X) + X --> 0 (PR27151)Sanjay Patel2018-03-141-18/+12
| | | | | | | | | | | | | | | | As shown in: https://bugs.llvm.org/show_bug.cgi?id=27151 ...the existing fold could miscompile when X is NaN. The fold was also dependent on 'ninf' but that's not necessary. From IEEE-754 (with default rounding which we can assume for these opcodes): "When the sum of two operands with opposite signs (or the difference of two operands with like signs) is exactly zero, the sign of that sum (or difference) shall be +0...However, x + x = x − (−x) retains the same sign as x even when x is zero." llvm-svn: 327575
* [InstSimplify] add tests to show missing/broken fadd folds (PR27151, ↵Sanjay Patel2018-03-141-27/+77
| | | | | | PR26958); NFC llvm-svn: 327554
* [InstSimplify] regenerate checks; NFCSanjay Patel2018-03-141-24/+24
| | | | llvm-svn: 327553
* [InstSimplify] [NFC] cast-unsigned-icmp-cmp-0.ll - don't run instcombineRoman Lebedev2018-03-141-4/+1
| | | | | | | As disscussed in post-commit review of D44421, there is simply no reason to run instcombine on this testcase. llvm-svn: 327541
* [InstSimplify] [NFC] Add tests for peeking through unsigned FP casts for ↵Roman Lebedev2018-03-141-0/+247
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sign compares (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked (input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`) for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean: * `slt 0` * `sgt -1` I did not check vectors, but i'm guessing it's the same there. {F5889242} Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle). There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized. Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44421 llvm-svn: 327535
* [PatternMatch] enhance m_NaN() to ignore undef elements in vectorsSanjay Patel2018-03-121-4/+2
| | | | llvm-svn: 327339
* [InstSimplify] add fcmp tests for constant NaN vector with undef elt; NFCSanjay Patel2018-03-121-1/+19
| | | | llvm-svn: 327335
* [PatternMatch, InstSimplify] allow undef elements when matching vector -0.0Sanjay Patel2018-03-121-7/+3
| | | | | | | | | This is the FP equivalent of D42818. Use it for the few cases in InstSimplify with -0.0 folds (that's the only current use of m_NegZero()). Differential Revision: https://reviews.llvm.org/D43792 llvm-svn: 327307
* [InstSimplify] add test for m_NegZero with undef elt; NFCSanjay Patel2018-03-121-0/+9
| | | | llvm-svn: 327287
* [InstSimplify] fp_binop X, undef --> NaNSanjay Patel2018-03-101-32/+20
| | | | | | The variable operand could be NaN, so it's always safe to propagate NaN. llvm-svn: 327212
* [ConstantFold] fp_binop AnyConstant, undef --> NaNSanjay Patel2018-03-101-30/+30
| | | | | | | | | | | | | | | | | | With the updated LangRef ( D44216 / rL327138 ) in place, we can proceed with more constant folding. I'm intentionally taking the conservative path here: no matter what the constant or the FMF, we can always fold to NaN. This is because the undef operand can be chosen as NaN, and in our simplified default FP env, nothing else happens - NaN just propagates to the result. If we find some way/need to propagate undef instead, that can be added subsequently. The tests show that we always choose the same quiet NaN constant (0x7FF8000000000000 in IR text). There were suggestions to improve that with a 'NaN' string token or not always print a 64-bit hex value, but those are independent changes. We might also consider setting/propagating the payload of NaN constants as an enhancement. Differential Revision: https://reviews.llvm.org/D44308 llvm-svn: 327208
* [InstSimplify] fix FP infinite hex constant values in tests; NFCSanjay Patel2018-03-091-8/+8
| | | | | | Really should improve this... llvm-svn: 327144
* [ConstantFold] fp_binop undef, undef --> undefSanjay Patel2018-03-081-5/+5
| | | | | | | | | | | | | | | | | These are uncontroversial and independent of a proposed LangRef edits (D44216). I tried to fix tests that would fold away: rL327004 rL327028 rL327030 rL327034 I'm not sure if the Reassociate tests are meaningless yet, but they probably will be as we add more folds, so if anyone has suggestions or wants to fix those, please do. Differential Revision: https://reviews.llvm.org/D44258 llvm-svn: 327058
* [InstSimplify] add more tests for FP undef; NFCSanjay Patel2018-03-081-0/+376
| | | | llvm-svn: 327012
* [InstSimplify] add tests for FP with undef operand; NFCSanjay Patel2018-02-272-18/+89
| | | | | | Are any of these correct? llvm-svn: 326241
* [ValueTracking] Teach cannotBeOrderedLessThanZeroImpl to look through ↵Craig Topper2018-02-271-0/+14
| | | | | | | | | | ExtractElement. This is similar to what's done in computeKnownBits and computeSignBits. Don't do anything fancy just collect information valid for any element. Differential Revision: https://reviews.llvm.org/D43789 llvm-svn: 326237
* [InstCombine, InstSimplify] add tests with undef elements in constant FP ↵Sanjay Patel2018-02-261-0/+29
| | | | | | vectors; NFC llvm-svn: 326148
* [ValueTracking] Teach cannotBeOrderedLessThanZeroImpl to handle vector ↵Craig Topper2018-02-261-4/+2
| | | | | | | | | | | | | | | | constants. Summary: This allows vector fabs to be removed in more cases. Reviewers: spatel, arsenm, RKSimon Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43739 llvm-svn: 326138
* [InstSimplify] Add test cases for removal of vector fabs on known positive.Craig Topper2018-02-251-0/+118
| | | | llvm-svn: 326050
* [InstSimplify] Remove unused parameter from test cases.Craig Topper2018-02-251-7/+7
| | | | llvm-svn: 326049
* [InstSimplify] sqrt(X) * sqrt(X) --> XSanjay Patel2018-02-231-0/+15
| | | | | | This was misplaced in InstCombine. We can loosen the FMF as a follow-up step. llvm-svn: 325965
* [PatternMatch] enhance m_SignMask() to ignore undef elements in vectorsSanjay Patel2018-02-201-6/+2
| | | | llvm-svn: 325623
* [InstSimplify] add tests for m_SignMask with undef vector elements; NFCSanjay Patel2018-02-201-2/+28
| | | | llvm-svn: 325622
* [PatternMatch, InstSimplify] enhance m_AllOnes() to ignore undef elements in ↵Sanjay Patel2018-02-182-4/+2
| | | | | | | | | | | | | | | | | | | vectors Loosening the matcher definition reveals a subtle bug in InstSimplify (we should not assume that because an operand constant matches that it's safe to return it as a result). So I'm making that change here too (that diff could be independent, but I'm not sure how to reveal it before the matcher change). This also seems like a good reason to *not* include matchers that capture the value. We don't want to encourage the potential misstep of propagating undef values when it's not allowed/intended. I didn't include the capture variant option here or in the related rL325437 (m_One), but it already exists for other constant matchers. llvm-svn: 325466
* [InstSimplify] add tests with vector undef elts; NFCSanjay Patel2018-02-182-7/+18
| | | | llvm-svn: 325465
* [PatternMatch] enhance m_One() to ignore undef elements in vectorsSanjay Patel2018-02-171-6/+3
| | | | llvm-svn: 325437
* [InstSimplify, InstCombine] add tests with vector undef elts; NFCSanjay Patel2018-02-171-0/+28
| | | | | | These would fold if the m_One pattern matcher accounted for undef elts. llvm-svn: 325436
* [InstSimplify] add vector select tests with undef elts in condition; NFCSanjay Patel2018-02-171-0/+20
| | | | llvm-svn: 325419
* [InstCombine, InstSimplify] (re)move tests, regenerate checks; NFCSanjay Patel2018-02-132-58/+124
| | | | | | | | The InstCombine integer mul test file had tests that belong in InstSimplify (including fmul tests). Move things to where they belong and auto-generate complete checks for everything. llvm-svn: 325037
* [InstSimplify] allow exp/log simplifications with only 'reassoc' FMFSanjay Patel2018-02-121-47/+46
| | | | | | | | | | These intrinsic folds were added with D41381, but only allowed with isFast(). That's more than necessary because FMF has 'reassoc' to apply to these kinds of folds after D39304, and that's all we need in these cases. Differential Revision: https://reviews.llvm.org/D43160 llvm-svn: 324967
* [InstSimplify] change tests to 'fast' to reflect current foldsSanjay Patel2018-02-121-76/+52
| | | | | | | | The diff to use 'reassoc' is part of D43160; it should not have been made with rL324961. Reverting that part here, so we'll see the intended diff with the code change. llvm-svn: 324963
* [InstSimplify] consolidate tests for log-exp inverse foldsSanjay Patel2018-02-125-284/+217
| | | | | | | | | | | Some tests didn't add much value because we already show stronger constraints for the folds in other tests, so the weaker versions were deleted. Moved the remaining tests into 1 file because the folds are very similar and handled from 1 place in the code. llvm-svn: 324961
* [ValueTracking] don't crash when assumptions conflict (PR36270)Sanjay Patel2018-02-081-0/+21
| | | | | | | | | | | | | | The last assume in the test says that %B12 is 0. The first assume says that %and1 is less than %B12. Therefore, %and1 is unsigned less than 0...does not compute. That means this line: Known.Zero.setHighBits(RHSKnown.countMinLeadingZeros() + 1); ...tries to set more bits than exist. Differential Revision: https://reviews.llvm.org/D43052 llvm-svn: 324610
* [InstSimplify] (X * Y) / Y --> X for relaxed floating-point opsSanjay Patel2018-01-301-0/+34
| | | | | | | | | This is the FP counterpart that was mentioned in PR35709: https://bugs.llvm.org/show_bug.cgi?id=35709 Differential Revision: https://reviews.llvm.org/D42385 llvm-svn: 323716
* InstSimplify: If divisor element is undef simplify to undefZvi Rackover2018-01-242-0/+32
| | | | | | | | | | | | | | | | Summary: If any vector divisor element is undef, we can arbitrarily choose it be zero which would make the div/rem an undef value by definition. Reviewers: spatel, reames Reviewed By: spatel Subscribers: magabari, llvm-commits Differential Revision: https://reviews.llvm.org/D42485 llvm-svn: 323343
* [InstSimplify] (X << Y) % X -> 0Anton Bikineev2018-01-231-12/+4
| | | | llvm-svn: 323182
* [InstSimplify] add baseline tests for (X << Y) % X -> 0; NFCSanjay Patel2018-01-211-12/+82
| | | | | | | | | | | This is the 'rem' counterpart to D42032 and would be folded by D42341. Patch by Anton Bikineev. Differential Revision: https://reviews.llvm.org/D42342 llvm-svn: 323067
* [InstSimplify] regenerate checks and add tests for commutes; NFCSanjay Patel2018-01-181-49/+92
| | | | llvm-svn: 322907
* [InstSimplify] fold implied null ptr check (PR35790)Sanjay Patel2018-01-131-24/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This extends rL322327 to handle the pointer cast and should solve: https://bugs.llvm.org/show_bug.cgi?id=35790 Name: or_eq_zero %isnull = icmp eq i64* %p, null %x = ptrtoint i64* %p to i64 %somebits = and i64 %x, %y %somebits_are_zero = icmp eq i64 %somebits, 0 %or = or i1 %somebits_are_zero, %isnull => %or = %somebits_are_zero Name: and_ne_zero %isnotnull = icmp ne i64* %p, null %x = ptrtoint i64* %p to i64 %somebits = and i64 %x, %y %somebits_are_not_zero = icmp ne i64 %somebits, 0 %and = and i1 %somebits_are_not_zero, %isnotnull => %and = %somebits_are_not_zero https://rise4fun.com/Alive/CQ3 llvm-svn: 322439
OpenPOWER on IntegriCloud