aboutsummaryrefslogtreecommitdiff
path: root/test/Transforms/InstCombine/icmp.ll
AgeCommit message (Collapse)Author
2013-03-25Address issues found by Duncan during post-commit review of r177856.Arnaud A. de Grandmaison
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177863 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-25InstCombine: simplify comparisons to zero of (shl %x, Cst) or (mul %x, Cst)Arnaud A. de Grandmaison
This simplification happens at 2 places : - using the nsw attribute when the shl / mul is used by a sign test - when the shl / mul is compared for (in)equality to zero git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177856 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-15Teach InstCombine to work with smaller legal types in icmp (shl %v, C1), C2Arnaud A. de Grandmaison
It enables to work with a smaller constant, which is target friendly for those which can compare to immediates. It also avoids inserting a shift in favor of a trunc, which can be free on some targets. This used to work until LLVM-3.1, but regressed with the 3.2 release. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175270 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-31Add extra CHECK to make sure that 'or' instruction was replaced.Jakub Staszak
Also add an assert to avoid confusion in the code where is known that C1 <= C2. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171310 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-31Transform (A == C1 || A == C2) into (A & ~(C1 ^ C2)) == C1Jakub Staszak
if C1 and C2 differ only with one bit. Fixes PR14708. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171270 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19Transform (x&C)>V into (x&C)!=0 where possiblePaul Redmond
When the least bit of C is greater than V, (x&C) must be greater than V if it is not zero, so the comparison can be simplified. Although this was suggested in Target/X86/README.txt, it benefits any architecture with a directly testable form of AND. Patch by Kevin Schoedel git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170576 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-13Revert r170020, "Simplify negated bit test", for now.NAKAMURA Takumi
This assumes (1 << n) is always not zero. Consider n is greater than word size. Although I know it is undefined, this transforms undefined behavior hidden. This led clang unexpected behavior with some failures. I will investigate to fix undefined shl in clang. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170128 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-12Simplify negated bit testDavid Majnemer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170020 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-16Fix PR14361: wrong simplification of A+B==B+A. You may think that the old logicDuncan Sands
replaced by this patch is equivalent to the new logic, but you'd be wrong, and that's exactly where the bug was. There's a similar bug in instsimplify which manifests itself as instsimplify failing to simplify this, rather than doing it wrong, see next commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168181 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-10InstCombine: Turn (zext A) == (B & (1<<X)-1) into A == (trunc B), narrowing ↵Benjamin Kramer
the compare. This saves a cast, and zext is more expensive on platforms with subreg support than trunc is. This occurs in the BSD implementation of memchr(3), see PR12750. On the synthetic benchmark from that bug stupid_memchr and bsd_memchr have the same performance now when not inlining either function. stupid_memchr: 323.0us bsd_memchr: 321.0us memchr: 479.0us where memchr is the llvm-gcc compiled bsd_memchr from osx lion's libc. When inlining is enabled bsd_memchr still regresses down to llvm-gcc memchr time, I haven't fully understood the issue yet, something is grossly mangling the loop after inlining. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158297 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-26Reinstate the optimization from r151449 with a fix to not turn 'gep %x' intoNick Lewycky
'gep null' when the icmp predicate is unsigned (or is signed without inbounds). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151467 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-25Roll these back to r151448 until I figure out how they're breakingNick Lewycky
MultiSource/Applications/lua. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151463 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-25Teach instsimplify to be more aggressive when analyzing comparisons of pointersNick Lewycky
by using llvm::isIdentifiedObject. Also teach it to handle GEPs that have the same base pointer and constant operands. Fixes PR11238! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151449 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-21InstCombine: Don't transform a signed icmp of two GEPs into a signed compare ↵Benjamin Kramer
of the indices. This transformation is not safe in some pathological cases (signed icmp of pointers should be an extremely rare thing, but it's valid IR!). Add an explanatory comment. Kudos to Duncan for pointing out this edge case (and not giving up explaining it until I finally got it). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151055 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-20Test case for r150978.Benjamin Kramer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150979 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-20InstCombine: When comparing two GEPs that were derived from the same base ↵Benjamin Kramer
pointer but use different types, expand the offset calculation and to the compare on the offset if profitable. This came up in SmallVector code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150962 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-27Add r149110 back with a fix for when the vector and the int have the sameRafael Espindola
width. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149151 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-27Revert r149110 and add a testcase that was crashing since that revision.Rafael Espindola
Unfortunately I also had to disable constant-pool-sharing.ll the code it tests has been updated to use the IL logic. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149148 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-27enhance constant folding to be able to constant fold bitcast of Chris Lattner
ConstantVector's to integer type. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149110 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-05FileCheck hygiene.Benjamin Kramer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147580 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-01Improved fix for abs(val) != 0 to check other similar case. Also fixed ↵Pete Cooper
style issues and confusing comment git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145618 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-01Removed use of grep from test and moved it to be with other icmp testsPete Cooper
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145570 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-04PR10267: Don't combine an equality compare with an AND into an inequality ↵Benjamin Kramer
compare when the AND has more than one use. This can pessimize code, inequalities are generally more expensive. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134379 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-13InstCombine: Fold A-b == C --> b == A-C if A and C are constants.Benjamin Kramer
The backend already knew this trick. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132915 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-12InstCombine: Shrink ((zext X) & C1) == C2 to fold away the cast if the ↵Benjamin Kramer
"zext" and the "and" have one use. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132897 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-05PR9838: Fix transform introduced in r127064 to not trigger when only one ↵Eli Friedman
side of the icmp is an exact shift. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130954 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-26Transform: "icmp eq (trunc (lshr(X, cst1)), cst" to "icmp (and X, mask), cst"Chris Lattner
when X has multiple uses. This is useful for exposing secondary optimizations, but the X86 backend isn't ready for this when X has a single use. For example, this can disable load folding. This is inching towards resolving PR6627. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130238 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-09Fix mistyped CHECK lines.Benjamin Kramer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127366 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-07Tweak this test. We can analyze what happens and show that we still do theNick Lewycky
right thing, instead of merely being unable to analyze and the transform doesn't occur. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127149 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-07Add more analysis of the sign bit of an srem instruction. If the LHS is negativeNick Lewycky
then the result could go either way. If it's provably positive then so is the srem. Fixes PR9343 #7! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127146 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-06ConstantInt has some getters which return ConstantInt's or ConstantVector's ofNick Lewycky
the value splatted into every element. Extend this to getTrue and getFalse which by providing new overloads that take Types that are either i1 or <N x i1>. Use it in InstCombine to add vector support to some code, fixing PR8469! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127116 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-05Thread comparisons over udiv/sdiv/ashr/lshr exact and lshr nuw/nsw wheneverNick Lewycky
possible. This goes into instcombine and instsimplify because instsimplify doesn't need to check hasOneUse since it returns (almost exclusively) constants. This fixes PR9343 #4 #5 and #8! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127064 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-05Try once again to optimize "icmp (srem X, Y), Y" by turning the comparison intoNick Lewycky
true/false or "icmp slt/sge Y, 0". git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127063 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-04Fold "icmp pred (srem X, Y), Y" like we do for urem. Handle signed comparisonsNick Lewycky
in the urem case, though not the other way around. This is enough to get #3 from PR9343! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126991 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-28srem doesn't actually have the same resulting sign as its numerator, you couldNick Lewycky
also have a zero when numerator = denominator. Reverts parts of r126635 and r126637. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126644 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-28Teach InstCombine to fold "(shr exact X, Y) == 0" --> X == 0, fixing #1 fromNick Lewycky
PR9343. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126643 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-28The sign of an srem instruction is the sign of its dividend (the firstNick Lewycky
argument), regardless of the divisor. Teach instcombine about this and fix test7 in PR9343! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126635 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-18Add some transforms of the kind X-Y>X -> 0>Y which are valid when there is noDuncan Sands
overflow. These subsume some existing equality transforms, so zap those. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125843 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-17Transform "A + B >= A + C" into "B >= C" if the adds do not wrap. Likewise ↵Duncan Sands
for some variations (some of these were already present so I unified the code). Spotted by my auto-simplifier as occurring a lot. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125734 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-10implement the first part of PR8882: when lowering an inboundsChris Lattner
gep to explicit addressing, we know that none of the intermediate computation overflows. This could use review: it seems that the shifts certainly wouldn't overflow, but could the intermediate adds overflow if there is a negative index? Previously the testcase would instcombine to: define i1 @test(i64 %i) { %p1.idx.mask = and i64 %i, 4611686018427387903 %cmp = icmp eq i64 %p1.idx.mask, 1000 ret i1 %cmp } now we get: define i1 @test(i64 %i) { %cmp = icmp eq i64 %i, 1000 ret i1 %cmp } git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125271 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-09merge two tests.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125195 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-11Fix a random missed optimization by making InstCombine more aggressive when ↵Owen Anderson
determining which bits are demanded by a comparison against a constant. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123203 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-23duncan's spider sense was right, I completely reversed the conditionChris Lattner
on this instcombine xform. This fixes a miscompilation of 403.gcc. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119988 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-21optimize:Chris Lattner
void a(int x) { if (((1<<x)&8)==0) b(); } into "x != 3", which occurs over 100 times in 403.gcc but in no other program in llvm-test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119922 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-28Constant fold x == undef to undef.Dan Gohman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107074 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-03fix incorrect folding of icmp with undef, PR6481.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97659 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-01fix PR6195, a bug constant folding scalar -> vector compares.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94997 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-21enhance x-(-A) -> x+A to preserve NUW/NSW.Chris Lattner
Use the presence of NSW/NUW to fold "icmp (x+cst), x" to a constant in cases where it would otherwise be undefined behavior. Surprisingly (to me at least), this triggers hundreds of the times in a few benchmarks: lencode, ldecode, and 466.h264ref seem to *really* like this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91812 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-21Optimize all cases of "icmp (X+Cst), X" to something simpler. This triggersChris Lattner
a bunch in lencode, ldecod, spass, 176.gcc, 252.eon, among others. It is also the first part of PR5822 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91811 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-21convert to filecheckChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91810 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2024-11-21 21:29:47 +0000