summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/div.ll
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Extend `0 - (X sdiv C) -> (X sdiv -C)` fold to non-splat vectorsRoman Lebedev2019-12-051-6/+3
| | | | Split off from https://reviews.llvm.org/D68408
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+1049
| | | | | | | | 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-171-1049/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [InstCombine] Canonicalize (-X s/ Y) to -(X s/ Y).Chen Zheng2019-04-101-6/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D60395 llvm-svn: 358050
* [InstCombine] prevent possible miscompile with sdiv+negate of vector opSanjay Patel2019-04-091-4/+7
| | | | | | | | | | | Similar to: rL358005 Forego folding arbitrary vector constants to fix a possible miscompile bug. We can enhance the transform if we do want to handle the more complicated vector case. llvm-svn: 358013
* [InstCombine] add tests for sdiv with negated dividend and constant divisor; NFCSanjay Patel2019-04-091-12/+97
| | | | llvm-svn: 358010
* [InstCombine] add tests for sdiv-by-int-min; NFCSanjay Patel2019-04-091-0/+30
| | | | llvm-svn: 358008
* [InstCombine] prevent possible miscompile with negate+sdiv of vector opSanjay Patel2019-04-091-4/+6
| | | | | | | | | | | | | | // 0 - (X sdiv C) -> (X sdiv -C) provided the negation doesn't overflow. This fold has been around for many years and nobody noticed the potential vector miscompile from overflow until recently... So it seems unlikely that there's much demand for a vector sdiv optimization on arbitrary vector constants, so just limit the matching to splat constants to avoid the possible bug. Differential Revision: https://reviews.llvm.org/D60426 llvm-svn: 358005
* [InstCombine] add tests/comments for negate+sdiv; NFCSanjay Patel2019-04-091-0/+35
| | | | llvm-svn: 358003
* [InstCombine] add tests for negate+sdiv; NFCSanjay Patel2019-04-081-0/+51
| | | | | | | PR41425: https://bugs.llvm.org/show_bug.cgi?id=41425 llvm-svn: 357953
* [InstCombine] sdiv exact flag fixup.Chen Zheng2019-04-081-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D60396 llvm-svn: 357904
* [InstCombine] add more testcases for sdiv exact flag fixup.Chen Zheng2019-04-081-6/+68
| | | | llvm-svn: 357894
* [InstCombine] add testcases for sdiv exact flag fixing - NFC.Chen Zheng2019-04-081-0/+19
| | | | llvm-svn: 357884
* [InstCombine] fold udiv with common factor from muls with nuwSanjay Patel2018-07-261-12/+4
| | | | | | | | | Unfortunately, sdiv isn't as simple because of UB due to overflow. This fold is mentioned in PR38239: https://bugs.llvm.org/show_bug.cgi?id=38239 llvm-svn: 338059
* [InstCombine] add tests for udiv with common factor; NFCSanjay Patel2018-07-261-0/+82
| | | | | | | | | | | This fold is mentioned in PR38239: https://bugs.llvm.org/show_bug.cgi?id=38239 The general case probably belongs in -reassociate, but given that we do basic reassociation optimizations similar to this in instcombine already, we might as well be consistent within instcombine and handle this pattern? llvm-svn: 338038
* [InstCombine] fold udiv with sext bool divisorSanjay Patel2018-06-261-4/+4
| | | | | | | | | | Note: I didn't add a hasOneUse() check because the existing, related fold doesn't have that check. I suspect that the improved analysis and codegen make these some of the rare canonicalization cases where we allow an increase in instructions. llvm-svn: 335597
* [InstCombine] add/move tests for udiv; NFCSanjay Patel2018-06-251-0/+52
| | | | llvm-svn: 335544
* [InstCombine] fold sdiv with sext bool divisorSanjay Patel2018-06-251-4/+2
| | | | llvm-svn: 335527
* [InstCombine] add tests for sdiv with sext bool divisor; NFCSanjay Patel2018-06-251-84/+112
| | | | llvm-svn: 335526
* [InstSimplify] move/add/regenerate checks for tests; NFCSanjay Patel2018-04-211-9/+0
| | | | llvm-svn: 330515
* [InstCombine] X / (X * Y) -> 1 / Y if the multiplication does not overflowSanjay Patel2018-02-111-12/+14
| | | | | | | | | | | The related cases for (X * Y) / X were handled in rL124487. https://rise4fun.com/Alive/6k9 The division in these tests is subsequently eliminated by existing instcombines for 1/X. llvm-svn: 324843
* [InstCombine] add tests for div-mul folds; NFCSanjay Patel2018-02-111-0/+53
| | | | | | The related cases for (X * Y) / X were handled in rL124487. llvm-svn: 324840
* [InstCombine] Fix a vector splat handling bug in transformZExtICmp.Craig Topper2017-10-051-0/+9
| | | | | | | | | | We were using an i1 type and then zero extending to a vector. Instead just create the 0/1 directly as a ConstantInt with the correct type. No need to ask ConstantExpr to zero extend for us. This bug is a bit tricky to hit because it requires us to visit a zext of an icmp that would normally be simplified to true/false, but that icmp hasnt' been visited yet. In the test case this zext and icmp were created by visiting a udiv and due to worklist ordering we got to the zext first. Fixes PR34841. llvm-svn: 314971
* [InstSimplify] fold sdiv/srem based on compare of dividend and divisorSanjay Patel2017-09-141-8/+5
| | | | | | | | | | | | | | | 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
* [InstCombine] Simplify 1/X for vectors.Craig Topper2017-04-171-2/+5
| | | | llvm-svn: 300439
* [InstCombine] Add test cases for missing support for simplifying 1/X for ↵Craig Topper2017-04-171-0/+18
| | | | | | vectors. NFC llvm-svn: 300438
* [InstCombine] Add support for turning vector sdiv into udiv.Craig Topper2017-04-171-6/+3
| | | | llvm-svn: 300435
* [InstCombine] Add test cases for missing support for turning vector sdiv ↵Craig Topper2017-04-171-0/+11
| | | | | | into udiv. NFC llvm-svn: 300434
* [InstCombine] allow icmp (div X, Y), C folds for splat constant vectorsSanjay Patel2016-08-311-10/+5
| | | | | | Converting all of the overflow ops to APInt looked risky, so I've left that as a TODO. llvm-svn: 280299
* [InstCombine] add tests for missing vector icmp foldsSanjay Patel2016-08-151-0/+36
| | | | llvm-svn: 278717
* [InstCombine] shrink type of sdiv if dividend is sexted and constant divisor ↵Sanjay Patel2016-06-271-9/+21
| | | | | | | | | | | is small enough (PR28153) This should fix PR28153: https://llvm.org/bugs/show_bug.cgi?id=28153 Differential Revision: http://reviews.llvm.org/D21769 llvm-svn: 273951
* add tests for PR28153Sanjay Patel2016-06-271-0/+76
| | | | llvm-svn: 273936
* [ValueTracking, InstCombine] extend isKnownToBeAPowerOfTwo() to handle ↵Sanjay Patel2016-05-221-1/+1
| | | | | | | | | | | | | | vector splat constants We could try harder to handle non-splat vector constants too, but that seems much rarer to me. Note that the div test isn't resolved because there's a check for isIntegerTy() guarding that transform. Differential Revision: http://reviews.llvm.org/D20497 llvm-svn: 270369
* add test vector sdivSanjay Patel2016-05-201-0/+15
| | | | llvm-svn: 270285
* [InstCombine] regenerate checksSanjay Patel2016-05-021-131/+183
| | | | llvm-svn: 268241
* Handle non-constant shifts in computeKnownBits, and use computeKnownBits for ↵Hal Finkel2015-10-231-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constant folding in InstCombine/Simplify First, the motivation: LLVM currently does not realize that: ((2072 >> (L == 0)) >> 7) & 1 == 0 where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the lowest-order bit is always zero. There are obviously several ways to go about fixing this, but the generic solution pursued in this patch is to teach computeKnownBits something about shifts by a non-constant amount. Previously, we would give up completely on these. Instead, in cases where we know something about the low-order bits of the shift-amount operand, we can combine (and together) the associated restrictions for all shift amounts consistent with that knowledge. As a further generalization, I refactored all of the logic for all three kinds of shifts to have this capability. This works well in the above case, for example, because the dynamic shift amount can only be 0 or 1, and thus we can say a lot about the known bits of the result. This brings us to the second part of this change: Even when we know all of the bits of a value via computeKnownBits, nothing used to constant-fold the result. This introduces the necessary code into InstCombine and InstSimplify. I've added it into both because: 1. InstCombine won't automatically pick up the associated logic in InstSimplify (InstCombine uses InstSimplify, but not via the API that passes in the original instruction). 2. Putting the logic in InstCombine allows the resulting simplifications to become part of the iterative worklist 3. Putting the logic in InstSimplify allows the resulting simplifications to be used by everywhere else that calls SimplifyInstruction (inlining, unrolling, and many others). And this requires a small change to our definition of an ephemeral value so that we don't break the rest case from r246696 (where the icmp feeding the @llvm.assume, is also feeding a br). Under the old definition, the icmp would not be considered ephemeral (because it is used by the br), but this causes the assume to remove itself (in addition to simplifying the branch structure), and it seems more-useful to prevent that from happening. llvm-svn: 251146
* [InstCombine] Don't divide by zero when evaluating a potential transformDavid Majnemer2015-09-061-0/+18
| | | | | | | | | | Trivial multiplication by zero may survive the worklist. We tried to reassociate the multiplication with a division instruction, causing us to divide by zero; bail out instead. This fixes PR24726. llvm-svn: 246939
* Fix a bunch of trivial cases of 'CHECK[^:]*$' in the tests. NFCIJonathan Roelofs2015-08-101-1/+1
| | | | | | | I looked into adding a warning / error for this to FileCheck, but there doesn't seem to be a good way to avoid it triggering on the instances of it in RUN lines. llvm-svn: 244481
* InstCombine: Propagate exact for (sdiv X, Pow2) -> (udiv X, Pow2)David Majnemer2014-11-221-0/+11
| | | | llvm-svn: 222625
* InstCombine: Propagate exact for (sdiv X, Y) -> (udiv X, Y)David Majnemer2014-11-221-0/+10
| | | | llvm-svn: 222624
* InstCombine: Propagate exact for (sdiv -X, C) -> (sdiv X, -C)David Majnemer2014-11-221-0/+9
| | | | llvm-svn: 222623
* InstCombine: Propagate exact in (udiv (lshr X,C1),C2) -> (udiv x,C1<<C2)David Majnemer2014-11-221-0/+9
| | | | llvm-svn: 222620
* InstCombine: Preserve nsw when folding X*(2^C) -> X << CDavid Majnemer2014-11-221-2/+2
| | | | llvm-svn: 222606
* InstCombine: Don't miscompile X % ((Pow2 << A) >>u B)David Majnemer2014-10-141-1/+13
| | | | | | | | | | | | | | | | | | | We assumed that A must be greater than B because the right hand side of a remainder operator must be nonzero. However, it is possible for A to be less than B if Pow2 is a power of two greater than 1. Take for example: i32 %A = 0 i32 %B = 31 i32 Pow2 = 2147483648 ((Pow2 << 0) >>u 31) is non-zero but A is less than B. This fixes PR21274. llvm-svn: 219713
* InstCombine: Don't miscompile (x lshr C1) udiv C2David Majnemer2014-10-131-3/+13
| | | | | | | | | | | | | We have a transform that changes: (x lshr C1) udiv C2 into: x udiv (C2 << C1) However, it is unsafe to do so if C2 << C1 discards any of C2's bits. This fixes PR21255. llvm-svn: 219634
* InstCombine: Don't fold (X <<s log(INT_MIN)) /s INT_MIN to XDavid Majnemer2014-10-111-0/+17
| | | | | | | | | | Consider the case where X is 2. (2 <<s 31)/s-2147483648 is zero but we would fold to X. Note that this is valid when we are in the unsigned domain because we require NUW: 2 <<u 31 results in poison. This fixes PR21245. llvm-svn: 219568
* InstCombine: mul to shl shouldn't preserve nswDavid Majnemer2014-10-111-2/+2
| | | | | | | | | | | | | | | | | consider: mul i32 nsw %x, -2147483648 this instruction will not result in poison if %x is 1 however, if we transform this into: shl i32 nsw %x, 31 then we will be generating poison because we just shifted into the sign bit. This fixes PR21242. llvm-svn: 219566
* InstCombine: Combine mul with div.David Majnemer2014-08-161-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can combne a mul with a div if one of the operands is a multiple of the other: %mul = mul nsw nuw %a, C1 %ret = udiv %mul, C2 => %ret = mul nsw %a, (C1 / C2) This can expose further optimization opportunities if we end up multiplying or dividing by a power of 2. Consider this small example: define i32 @f(i32 %a) { %mul = mul nuw i32 %a, 14 %div = udiv exact i32 %mul, 7 ret i32 %div } which gets CodeGen'd to: imull $14, %edi, %eax imulq $613566757, %rax, %rcx shrq $32, %rcx subl %ecx, %eax shrl %eax addl %ecx, %eax shrl $2, %eax retq We can now transform this into: define i32 @f(i32 %a) { %shl = shl nuw i32 %a, 1 ret i32 %shl } which gets CodeGen'd to: leal (%rdi,%rdi), %eax retq This fixes PR20681. llvm-svn: 215815
* Optimize integral reciprocal (udiv 1, x and sdiv 1, x) to not use division. ↵Nick Lewycky2014-05-141-0/+19
| | | | | | This fires exactly once in a clang bootstrap, but covers a few different results from http://www.cs.utah.edu/~regehr/souper/ llvm-svn: 208750
* InstCombine: Teach most integer add/sub/mul/div combines how to deal with ↵Benjamin Kramer2014-01-191-0/+24
| | | | | | vectors. llvm-svn: 199602
OpenPOWER on IntegriCloud