summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] canonicalize negated operand of fdivSanjay Patel2019-07-261-5/+4
| | | | | | | This is a transform that we use with fmul, so use it for fdiv too for consistency. llvm-svn: 367146
* [InstCombine] add tests for fdiv with negated operand; NFCSanjay Patel2019-07-261-0/+35
| | | | llvm-svn: 367145
* [InstCombine] remove flop from lerp patternsSanjay Patel2019-07-261-32/+24
| | | | | | | | | | | | | | | | | (Y * (1.0 - Z)) + (X * Z) --> Y - (Y * Z) + (X * Z) --> Y + Z * (X - Y) This is part of solving: https://bugs.llvm.org/show_bug.cgi?id=42716 Factoring eliminates an instruction, so that should be a good canonicalization. The potential conversion to FMA would be handled by the backend based on target capabilities. Differential Revision: https://reviews.llvm.org/D65305 llvm-svn: 367101
* [InstCombine] add tests for lerp patterns (PR42716); NFCSanjay Patel2019-07-251-0/+170
| | | | llvm-svn: 367069
* Revert "[InstCombine] try to narrow a truncated load"Vlad Tsyrklevich2019-07-251-50/+12
| | | | | | | | | This reverts commit bc4a63fd3c29c1a8ce22891bf34ee4dccfef578c, this is a speculative revert to fix a number of sanitizer bots (like sanitizer-x86_64-linux-bootstrap-ubsan) that have started to see stage2 compiler crashes, presumably due to a miscompile. llvm-svn: 367029
* [InstCombine] try to narrow a truncated loadSanjay Patel2019-07-251-12/+50
| | | | | | | | | | | | | | | | | | | | | | trunc (load X) --> load (bitcast X to narrow type) We have this transform in DAGCombiner::ReduceLoadWidth(), but the truncated load pattern can interfere with other instcombine transforms, so I'd like to allow the fold sooner. Example: https://bugs.llvm.org/show_bug.cgi?id=16739 ...in that report, we have bitcasts bracketing these ops, so those could get eliminated too. We've generally ruled out widening of loads early in IR ( LoadCombine - http://lists.llvm.org/pipermail/llvm-dev/2016-September/105291.html ), but that reasoning may not apply to narrowing if we can preserve information such as the dereferenceable range. Differential Revision: https://reviews.llvm.org/D64432 llvm-svn: 367011
* [InstCombine] Teach foldOrOfICmps to allow icmp eq MIN_INT/MAX to be part of ↵Craig Topper2019-07-241-28/+19
| | | | | | | | | | | | | | | a range comparision. Similar for foldAndOfICmps We can treat icmp eq X, MIN_UINT as icmp ule X, MIN_UINT and allow it to merge with icmp ugt X, C. Similar for the other constants. We can do simliar for icmp ne X, (U)INT_MIN/MAX in foldAndOfICmps. And we already handled UINT_MIN there. Fixes PR42691. Differential Revision: https://reviews.llvm.org/D65017 llvm-svn: 366945
* [InstCombine] Adjusted pow-exp tests for Windows [NFC]David Bolvansky2019-07-242-12/+12
| | | | | | | | | | | | | | | | Summary: https://bugs.llvm.org/show_bug.cgi?id=42740 Reviewers: efriedma, hans Reviewed By: hans Subscribers: spatel, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65220 llvm-svn: 366925
* AMDGPU: Fix test after r366913Matt Arsenault2019-07-241-20/+5
| | | | llvm-svn: 366916
* [InstCombine] add tests for load narrowing; NFCSanjay Patel2019-07-241-7/+43
| | | | | | Baseline results for D64432. llvm-svn: 366901
* [NFC][InstCombine] Fixup commutative/negative tests with icmp preds in ↵Roman Lebedev2019-07-232-12/+10
| | | | | | @llvm.umul.with.overflow tests llvm-svn: 366802
* [AMDGPU][NFC] Simplify test file for amdgcn intrinsicsHideto Ueno2019-07-231-5/+5
| | | | | | | | | | | | | | | | Summary: Remove unchecked attribute in the call site and use FileCheck String Substitution for `convergent` check. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64901 llvm-svn: 366781
* [InstCombine][NFC] Tests for canonicalization of unsigned multiply overflow ↵Roman Lebedev2019-07-224-0/+556
| | | | | | check llvm-svn: 366748
* [InstCombine] Add foldAndOfICmps test cases inspired by PR42691.Craig Topper2019-07-221-0/+39
| | | | | | | | | | icmp ne %x, INT_MIN can be treated similarly to icmp sgt %x, INT_MIN. icmp ne %x, INT_MAX can be treated similarly to icmp slt %x, INT_MAX. icmp ne %x, UINT_MAX can be treated similarly to icmp ult %x, UINT_MAX. We already treat icmp ne %x, 0 similarly to icmp ugt %x, 0 llvm-svn: 366662
* [NFC][InstCombine] Add a few extra srem-by-power-of-two tests - extra usesRoman Lebedev2019-07-211-0/+37
| | | | llvm-svn: 366652
* [NFC][InstCombine] Autogenerate a few testsRoman Lebedev2019-07-204-17/+53
| | | | llvm-svn: 366643
* [NFC][InstCombine] Add srem-by-signbit tests - still can fold to bittestRoman Lebedev2019-07-201-2/+46
| | | | | | https://rise4fun.com/Alive/IIeS llvm-svn: 366642
* [InstCombine] Fix copy/paste mistake in the test cases I added for PR42691. NFCCraig Topper2019-07-191-3/+5
| | | | llvm-svn: 366614
* [InstCombine] Add test cases for PR42691. NFCCraig Topper2019-07-191-0/+83
| | | | llvm-svn: 366611
* [NFC][InstCombine] Tests for 'rem' formation from sub-of-mul-by-'div' (PR42673)Roman Lebedev2019-07-192-0/+234
| | | | | | | https://rise4fun.com/Alive/8Rp https://bugs.llvm.org/show_bug.cgi?id=42673 llvm-svn: 366565
* [NFC][InstCombine] Redundant masking before left-shift: tests with assumeRoman Lebedev2019-07-194-22/+130
| | | | | | | | | | | | | | If the legality check is `(shiftNbits-maskNbits) s>= 0`, then we can simplify it to `shiftNbits u>= maskNbits`, which is easier to check for. However, currently switching the `dropRedundantMaskingOfLeftShiftInput()` to `SimplifyICmpInst()` does not catch these cases and regresses currently-handled cases, so i'll leave it as is for now. https://rise4fun.com/Alive/25P llvm-svn: 366564
* [InstCombine] Dropping redundant masking before left-shift [5/5] (PR42563)Roman Lebedev2019-07-191-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have some pattern that leaves only some low bits set, and then performs left-shift of those bits, if none of the bits that are left after the final shift are modified by the mask, we can omit the mask. There are many variants to this pattern: f. `((x << MaskShAmt) a>> MaskShAmt) << ShiftShAmt` All these patterns can be simplified to just: `x << ShiftShAmt` iff: f. `(ShiftShAmt-MaskShAmt) s>= 0` (i.e. `ShiftShAmt u>= MaskShAmt`) Normally, the inner pattern is sign-extend, but for our purposes it's no different to other patterns: alive proofs: f: https://rise4fun.com/Alive/7U3 For now let's start with patterns where both shift amounts are variable, with trivial constant "offset" between them, since i believe this is both simplest to handle and i think this is most common. But again, there are likely other variants where we could use ValueTracking/ConstantRange to handle more cases. https://bugs.llvm.org/show_bug.cgi?id=42563 Differential Revision: https://reviews.llvm.org/D64524 llvm-svn: 366540
* [InstCombine] Dropping redundant masking before left-shift [4/5] (PR42563)Roman Lebedev2019-07-191-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have some pattern that leaves only some low bits set, and then performs left-shift of those bits, if none of the bits that are left after the final shift are modified by the mask, we can omit the mask. There are many variants to this pattern: e. `((x << MaskShAmt) l>> MaskShAmt) << ShiftShAmt` All these patterns can be simplified to just: `x << ShiftShAmt` iff: e. `(ShiftShAmt-MaskShAmt) s>= 0` (i.e. `ShiftShAmt u>= MaskShAmt`) alive proofs: e: https://rise4fun.com/Alive/0FT For now let's start with patterns where both shift amounts are variable, with trivial constant "offset" between them, since i believe this is both simplest to handle and i think this is most common. But again, there are likely other variants where we could use ValueTracking/ConstantRange to handle more cases. https://bugs.llvm.org/show_bug.cgi?id=42563 Differential Revision: https://reviews.llvm.org/D64521 llvm-svn: 366539
* [InstCombine] Dropping redundant masking before left-shift [3/5] (PR42563)Roman Lebedev2019-07-191-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have some pattern that leaves only some low bits set, and then performs left-shift of those bits, if none of the bits that are left after the final shift are modified by the mask, we can omit the mask. There are many variants to this pattern: d. `(x & ((-1 << MaskShAmt) >> MaskShAmt)) << ShiftShAmt` All these patterns can be simplified to just: `x << ShiftShAmt` iff: d. `(ShiftShAmt-MaskShAmt) s>= 0` (i.e. `ShiftShAmt u>= MaskShAmt`) alive proofs: d: https://rise4fun.com/Alive/I5Y For now let's start with patterns where both shift amounts are variable, with trivial constant "offset" between them, since i believe this is both simplest to handle and i think this is most common. But again, there are likely other variants where we could use ValueTracking/ConstantRange to handle more cases. https://bugs.llvm.org/show_bug.cgi?id=42563 Differential Revision: https://reviews.llvm.org/D64519 llvm-svn: 366538
* [InstCombine] Dropping redundant masking before left-shift [2/5] (PR42563)Roman Lebedev2019-07-191-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have some pattern that leaves only some low bits set, and then performs left-shift of those bits, if none of the bits that are left after the final shift are modified by the mask, we can omit the mask. There are many variants to this pattern: c. `(x & (-1 >> MaskShAmt)) << ShiftShAmt` All these patterns can be simplified to just: `x << ShiftShAmt` iff: c. `(ShiftShAmt-MaskShAmt) s>= 0` (i.e. `ShiftShAmt u>= MaskShAmt`) alive proofs: c: https://rise4fun.com/Alive/RgJh For now let's start with patterns where both shift amounts are variable, with trivial constant "offset" between them, since i believe this is both simplest to handle and i think this is most common. But again, there are likely other variants where we could use ValueTracking/ConstantRange to handle more cases. https://bugs.llvm.org/show_bug.cgi?id=42563 Differential Revision: https://reviews.llvm.org/D64517 llvm-svn: 366537
* [InstCombine] Dropping redundant masking before left-shift [1/5] (PR42563)Roman Lebedev2019-07-191-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have some pattern that leaves only some low bits set, and then performs left-shift of those bits, if none of the bits that are left after the final shift are modified by the mask, we can omit the mask. There are many variants to this pattern: b. `(x & (~(-1 << maskNbits))) << shiftNbits` All these patterns can be simplified to just: `x << ShiftShAmt` iff: b. `(MaskShAmt+ShiftShAmt) u>= bitwidth(x)` alive proof: b: https://rise4fun.com/Alive/y8M For now let's start with patterns where both shift amounts are variable, with trivial constant "offset" between them, since i believe this is both simplest to handle and i think this is most common. But again, there are likely other variants where we could use ValueTracking/ConstantRange to handle more cases. https://bugs.llvm.org/show_bug.cgi?id=42563 Differential Revision: https://reviews.llvm.org/D64514 llvm-svn: 366536
* [InstCombine] Dropping redundant masking before left-shift [0/5] (PR42563)Roman Lebedev2019-07-191-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have some pattern that leaves only some low bits set, and then performs left-shift of those bits, if none of the bits that are left after the final shift are modified by the mask, we can omit the mask. There are many variants to this pattern: a. `(x & ((1 << MaskShAmt) - 1)) << ShiftShAmt` All these patterns can be simplified to just: `x << ShiftShAmt` iff: a. `(MaskShAmt+ShiftShAmt) u>= bitwidth(x)` alive proof: a: https://rise4fun.com/Alive/wi9 Indeed, not all of these patterns are canonical. But since this fold will only produce a single instruction i'm really interested in handling even uncanonical patterns, since i have this general kind of pattern in hotpaths, and it is not totally outlandish for bit-twiddling code. For now let's start with patterns where both shift amounts are variable, with trivial constant "offset" between them, since i believe this is both simplest to handle and i think this is most common. But again, there are likely other variants where we could use ValueTracking/ConstantRange to handle more cases. https://bugs.llvm.org/show_bug.cgi?id=42563 Reviewers: spatel, nikic, huihuiz, xbolva00 Reviewed By: xbolva00 Subscribers: efriedma, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64512 llvm-svn: 366535
* [InstCombine] Add assume context test; NFCNikita Popov2019-07-141-0/+74
| | | | | | Baseline test for D37215. llvm-svn: 366021
* Revert "[InstCombine] add tests for umin/umax via usub.sat; NFC"Sanjay Patel2019-07-131-72/+0
| | | | | | | | | This reverts commit rL365999 / 0f6148df23edcd3081f5e761de19edd4f823f16d. The tests already exist in this file, and the hoped-for transform (mentioned in D62871) is invalid because of undef as discussed in D63060. llvm-svn: 366000
* [InstCombine] add tests for umin/umax via usub.sat; NFCSanjay Patel2019-07-131-0/+72
| | | | llvm-svn: 365999
* [InstCombine] Fold select (icmp sgt x, -1), lshr (X, Y), ashr (X, Y) to ashr ↵David Bolvansky2019-07-121-105/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (X, Y)) Summary: (select (icmp sgt x, -1), lshr (X, Y), ashr (X, Y)) -> ashr (X, Y)) (select (icmp slt x, 1), ashr (X, Y), lshr (X, Y)) -> ashr (X, Y)) Fixes PR41173 Alive proof by @lebedev.ri (thanks) Name: PR41173 %cmp = icmp slt i32 %x, 1 %shr = lshr i32 %x, %y %shr1 = ashr i32 %x, %y %retval.0 = select i1 %cmp, i32 %shr1, i32 %shr => %retval.0 = ashr i32 %x, %y Optimization: PR41173 Done: 1 Optimization is correct! Reviewers: lebedev.ri, spatel Reviewed By: lebedev.ri Subscribers: nikic, craig.topper, llvm-commits, lebedev.ri Tags: #llvm Differential Revision: https://reviews.llvm.org/D64285 llvm-svn: 365893
* [InstCombine][NFCI] Add more test coverage to onehot_merge.llHuihui Zhang2019-07-111-0/+161
| | | | | | Prep work for upcoming patch D64275. llvm-svn: 365828
* [NFC] Revisited tests for D64285David Bolvansky2019-07-111-82/+201
| | | | llvm-svn: 365815
* [InstCombine] don't move FP negation out of a constant expressionSanjay Patel2019-07-111-0/+13
| | | | | | | -(X * ConstExpr) becomes X * (-ConstExpr), so don't reverse that and infinite loop. llvm-svn: 365774
* [NFC] Updated tests for D64285David Bolvansky2019-07-111-0/+380
| | | | llvm-svn: 365765
* [InstCombine] Reorder recently added/improved pow transformationsDavid Bolvansky2019-07-111-5/+8
| | | | | | Changed cases are now faster with exp2. llvm-svn: 365758
* [InstCombine][NFCI] Add test coverage to onehot_merge.llHuihui Zhang2019-07-111-0/+145
| | | | | | Prep work for upcoming patch D64275. llvm-svn: 365729
* Replace three "strip & accumulate" implementations with a single oneJohannes Doerfert2019-07-111-3/+2
| | | | | | | | | | | This patch replaces the three almost identical "strip & accumulate" implementations for constant pointer offsets with a single one, combining the respective functionalities. The old interfaces are kept for now. Differential Revision: https://reviews.llvm.org/D64468 llvm-svn: 365723
* [NFC][InstCombine] Comb through just-added "omit mask before left-shift" ↵Roman Lebedev2019-07-106-104/+159
| | | | | | tests once more llvm-svn: 365694
* [NFC][InstCombine] Fixup some tests in just-added "omit mask before ↵Roman Lebedev2019-07-103-10/+15
| | | | | | left-shift" tests llvm-svn: 365663
* [NFC][InstCombine] Redundant masking before left-shift (PR42563)Roman Lebedev2019-07-107-0/+1876
| | | | | | | | | | | | | | | | | | | | | | | alive proofs: a,b: https://rise4fun.com/Alive/4zsf c,d,e,f: https://rise4fun.com/Alive/RC49 Indeed, not all of these patterns are canonical. But since this fold will only produce a single instruction i'm really interested in handling even uncanonical patterns. Other than these 6 patterns, i can't think of any other reasonable variants right now, although i'm sure they exist. For now let's start with patterns where both shift amounts are variable, with trivial constant "offset" between them, since i believe this is both simplest to handle and i think this is most common. But again, there are likely other variants where we could use ValueTracking/ConstantRange to handle more cases. https://bugs.llvm.org/show_bug.cgi?id=42563 llvm-svn: 365641
* [InstCombine] pow(C,x) -> exp2(log2(C)*x)David Bolvansky2019-07-102-24/+40
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Transform pow(C,x) To exp2(log2(C)*x) if C > 0, C != inf, C != NaN (and C is not power of 2, since we have some fold for such case already). log(C) is folded by the compiler and exp2 is much faster to compute than pow. Reviewers: spatel, efriedma, evandro Reviewed By: evandro Subscribers: lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64099 llvm-svn: 365637
* [InstCombine] add tests for trunc(load); NFCSanjay Patel2019-07-091-0/+73
| | | | | | | | I'm not sure if transforming any of these is valid as a target-independent fold, but we might as well have a few tests here to confirm or deny our position. llvm-svn: 365523
* [InstCombine] fold insertelement into splat of same scalarSanjay Patel2019-07-082-6/+10
| | | | | | | | | | | | Forming the canonical splat shuffle improves analysis and may allow follow-on transforms (although some possibilities are missing as shown in the test diffs). The backend generically turns these patterns into build_vector, so there should be no codegen regressions. All targets are expected to be able to lower splats efficiently. llvm-svn: 365379
* [InstCombine] add tests for insert of same splatted scalar; NFCSanjay Patel2019-07-081-0/+69
| | | | llvm-svn: 365362
* [InstCombine] canonicalize insert+splat to/from element 0 of vectorSanjay Patel2019-07-081-6/+34
| | | | | | | | | | | We recognize a splat from element 0 in (VectorUtils) llvm::getSplatValue() and also in ShuffleVectorInst::isZeroEltSplatMask(), so this converts to that form for better matching. The backend generically turns these patterns into build_vector, so there should be no codegen difference. llvm-svn: 365342
* [InstCombine] fix typo in test; NFCSanjay Patel2019-07-081-3/+5
| | | | | | I added this test in rL365325, but didn't mean to create an undef insert. llvm-svn: 365333
* [InstCombine] add tests for splat shuffles; NFCSanjay Patel2019-07-081-0/+43
| | | | llvm-svn: 365325
* [InstCombine] allow undef elements when forming splat from chain of ↵Sanjay Patel2019-07-041-12/+17
| | | | | | | | | | | | | | | | | | insertelements We allow forming a splat (broadcast) shuffle, but we were conservatively limiting that to cases where all elements of the vector are specified. It should be safe from a codegen perspective to allow undefined lanes of the vector because the expansion of a splat shuffle would become the chain of inserts again. Forming splat shuffles can reduce IR and help enable further IR transforms. Motivating bugs: https://bugs.llvm.org/show_bug.cgi?id=42174 https://bugs.llvm.org/show_bug.cgi?id=16739 Differential Revision: https://reviews.llvm.org/D63848 llvm-svn: 365147
* [NFC] Added tests for D64099David Bolvansky2019-07-041-0/+241
| | | | llvm-svn: 365141
OpenPOWER on IntegriCloud