summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/icmp.ll
Commit message (Collapse)AuthorAgeFilesLines
...
* InstCombine: Optimize -x s< cstDavid Majnemer2014-05-151-0/+9
| | | | | | | | | | | | | | Summary: This gets rid of a sub instruction by moving the negation to the constant when valid. Reviewers: nicholas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D3773 llvm-svn: 208827
* Revert "InstCombine: merge constants in both operands of icmp."Erik Verbruggen2014-03-281-63/+0
| | | | | | | | | This reverts commit r204912, and follow-up commit r204948. This introduced a performance regression, and the fix is not completely clear yet. llvm-svn: 205010
* InstCombine: Don't combine constants on unsigned icmpsReid Kleckner2014-03-271-0/+10
| | | | | | | | | Fixes a miscompile introduced in r204912. It would miscompile code like (unsigned)(a + -49) <= 5U. The transform would turn this into (unsigned)a < 55U, which would return true for values in [0, 49], when it should not. llvm-svn: 204948
* InstCombine: merge constants in both operands of icmp.Erik Verbruggen2014-03-271-0/+53
| | | | | | | | | | Transform: icmp X+Cst2, Cst into: icmp X, Cst-Cst2 when Cst-Cst2 does not overflow, and the add has nsw. llvm-svn: 204912
* InstCombine: fold (A >> C) == (B >> C) --> (A^B) < (1 << C) for constant Cs.Benjamin Kramer2013-11-161-4/+24
| | | | | | This is common in bitfield code. llvm-svn: 194925
* [InstCombiner] Expose opportunities to merge subtract and comparison.Quentin Colombet2013-09-091-0/+65
| | | | | | | | | | | | | | | | | | | | | Several architectures use the same instruction to perform both a comparison and a subtract. The instruction selection framework does not allow to consider different basic blocks to expose such fusion opportunities. Therefore, these instructions are “merged” by CSE at MI IR level. To increase the likelihood of CSE to apply in such situation, we reorder the operands of the comparison, when they have the same complexity, so that they matches the order of the most frequent subtract. E.g., icmp A, B ... sub B, A <rdar://problem/14514580> llvm-svn: 190352
* Teach InstCombine about address spacesMatt Arsenault2013-08-211-7/+79
| | | | llvm-svn: 188926
* Catch more CHECK that can be converted to CHECK-LABEL in Transforms for ↵Stephen Lin2013-07-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | easier debugging. No functionality change. This conversion was done with the following bash script: find test/Transforms -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)define\([^@]*\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3define\4@$FUNC(/g" $TEMP done mv $TEMP $NAME fi done llvm-svn: 186269
* Update Transforms tests to use CHECK-LABEL for easier debugging. No ↵Stephen Lin2013-07-141-118/+118
| | | | | | | | | | | | | | | | | | | | | | functionality change. This update was done with the following bash script: find test/Transforms -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP done mv $TEMP $NAME fi done llvm-svn: 186268
* InstCombine: variations on 0xffffffff - x >= 4David Majnemer2013-07-091-0/+18
| | | | | | | | | | The following transforms are valid if -C is a power of 2: (icmp ugt (xor X, C), ~C) -> (icmp ult X, C) (icmp ult (xor X, C), -C) -> (icmp uge X, C) These are nice, they get rid of the xor. llvm-svn: 185915
* InstCombine: X & -C != -C -> X <= u ~CDavid Majnemer2013-07-091-40/+0
| | | | | | Tests were added in r185910 somehow. llvm-svn: 185912
* Commit r185909 was a misapplied patch, fix itDavid Majnemer2013-07-091-0/+58
| | | | llvm-svn: 185910
* InstCombine: add more transformsDavid Majnemer2013-07-091-0/+40
| | | | | | | | | C1-X <u C2 -> (X|(C2-1)) == C1 C1-X >u C2 -> (X|C2) == C1 X-C1 <u C2 -> (X & -C2) == C1 X-C1 >u C2 -> (X & ~C2) == C1 llvm-svn: 185909
* InstCombine: Fold X-C1 <u 2 -> (X & -2) == C1David Majnemer2013-07-081-0/+10
| | | | | | | | | | | Back in r179493 we determined that two transforms collided with each other. The fix back then was to reorder the transforms so that the preferred transform would give it a try and then we would try the secondary transform. However, it was noted that the best approach would canonicalize one transform into the other, removing the collision and allowing us to optimize IR given to us in that form. llvm-svn: 185808
* InstCombine: typo in or_icmp_eq_B_0_icmp_ult_A_B testDavid Majnemer2013-07-061-2/+2
| | | | llvm-svn: 185737
* InstCombine: (icmp eq B, 0) | (icmp ult A, B) -> (icmp ule A, B-1)David Majnemer2013-07-051-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This transform allows us to turn IR that looks like: %1 = icmp eq i64 %b, 0 %2 = icmp ult i64 %a, %b %3 = or i1 %1, %2 ret i1 %3 into: %0 = add i64 %b, -1 %1 = icmp uge i64 %0, %a ret i1 %1 which means we go from lowering: cmpq %rsi, %rdi setb %cl testq %rsi, %rsi sete %al orb %cl, %al ret to lowering: decq %rsi cmpq %rdi, %rsi setae %al ret llvm-svn: 185677
* InstCombine: Optimize (1 << X) Pred CstP2 to X Pred Log2(CstP2)David Majnemer2013-06-281-0/+104
| | | | | | | | | | | | | | We may, after other optimizations, find ourselves with IR that looks like: %shl = shl i32 1, %y %cmp = icmp ult i32 %shl, 32 Instead, we should just compare the shift count: %cmp = icmp ult i32 %y, 5 llvm-svn: 185242
* Add a testcase from pr16244.Rafael Espindola2013-06-061-0/+10
| | | | llvm-svn: 183433
* InstCombine: Don't just copy known bits from the first operand of an srem.Benjamin Kramer2013-05-091-0/+12
| | | | | | | That's obviously wrong. Conservatively restrict it to the sign bit, which matches the original intention of this analysis. Fixes PR15940. llvm-svn: 181518
* Reorders two transforms that collide with each otherDavid Majnemer2013-04-141-0/+12
| | | | | | | | | | | | | | | | | | | | | | One performs: (X == 13 | X == 14) -> X-13 <u 2 The other: (A == C1 || A == C2) -> (A & ~(C1 ^ C2)) == C1 The problem is that there are certain values of C1 and C2 that trigger both transforms but the first one blocks out the second, this generates suboptimal code. Reordering the transforms should be better in every case and allows us to do interesting stuff like turn: %shr = lshr i32 %X, 4 %and = and i32 %shr, 15 %add = add i32 %and, -14 %tobool = icmp ne i32 %add, 0 into: %and = and i32 %X, 240 %tobool = icmp ne i32 %and, 224 llvm-svn: 179493
* Simplify (A & ~B) in icmp if A is a power of 2David Majnemer2013-04-121-0/+26
| | | | | | | | The transform will execute like so: (A & ~B) == 0 --> (A & B) != 0 (A & ~B) != 0 --> (A & B) == 0 llvm-svn: 179386
* Optimize icmp involving addition betterDavid Majnemer2013-04-111-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | Allows LLVM to optimize sequences like the following: %add = add nsw i32 %x, 1 %cmp = icmp sgt i32 %add, %y into: %cmp = icmp sge i32 %x, %y as well as: %add1 = add nsw i32 %x, 20 %add2 = add nsw i32 %y, 57 %cmp = icmp sge i32 %add1, %add2 into: %add = add nsw i32 %y, 37 %cmp = icmp sle i32 %cmp, %x llvm-svn: 179316
* Address issues found by Duncan during post-commit review of r177856.Arnaud A. de Grandmaison2013-03-251-2/+2
| | | | llvm-svn: 177863
* InstCombine: simplify comparisons to zero of (shl %x, Cst) or (mul %x, Cst)Arnaud A. de Grandmaison2013-03-251-0/+142
| | | | | | | | 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 llvm-svn: 177856
* Teach InstCombine to work with smaller legal types in icmp (shl %v, C1), C2Arnaud A. de Grandmaison2013-02-151-0/+38
| | | | | | | | | 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. llvm-svn: 175270
* Add extra CHECK to make sure that 'or' instruction was replaced.Jakub Staszak2012-12-311-0/+1
| | | | | | Also add an assert to avoid confusion in the code where is known that C1 <= C2. llvm-svn: 171310
* Transform (A == C1 || A == C2) into (A & ~(C1 ^ C2)) == C1Jakub Staszak2012-12-311-0/+11
| | | | | | | if C1 and C2 differ only with one bit. Fixes PR14708. llvm-svn: 171270
* Transform (x&C)>V into (x&C)!=0 where possiblePaul Redmond2012-12-191-0/+17
| | | | | | | | | | | | 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 llvm-svn: 170576
* Revert r170020, "Simplify negated bit test", for now.NAKAMURA Takumi2012-12-131-26/+0
| | | | | | | | | 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. llvm-svn: 170128
* Simplify negated bit testDavid Majnemer2012-12-121-0/+26
| | | | llvm-svn: 170020
* Fix PR14361: wrong simplification of A+B==B+A. You may think that the old logicDuncan Sands2012-11-161-0/+18
| | | | | | | | | 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. llvm-svn: 168181
* InstCombine: Turn (zext A) == (B & (1<<X)-1) into A == (trunc B), narrowing ↵Benjamin Kramer2012-06-101-0/+22
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 158297
* Reinstate the optimization from r151449 with a fix to not turn 'gep %x' intoNick Lewycky2012-02-261-3/+1
| | | | | | 'gep null' when the icmp predicate is unsigned (or is signed without inbounds). llvm-svn: 151467
* Roll these back to r151448 until I figure out how they're breakingNick Lewycky2012-02-251-1/+3
| | | | | | MultiSource/Applications/lua. llvm-svn: 151463
* Teach instsimplify to be more aggressive when analyzing comparisons of pointersNick Lewycky2012-02-251-3/+1
| | | | | | | by using llvm::isIdentifiedObject. Also teach it to handle GEPs that have the same base pointer and constant operands. Fixes PR11238! llvm-svn: 151449
* InstCombine: Don't transform a signed icmp of two GEPs into a signed compare ↵Benjamin Kramer2012-02-211-0/+11
| | | | | | | | | | | 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). llvm-svn: 151055
* Test case for r150978.Benjamin Kramer2012-02-201-0/+13
| | | | llvm-svn: 150979
* InstCombine: When comparing two GEPs that were derived from the same base ↵Benjamin Kramer2012-02-201-0/+26
| | | | | | | | pointer but use different types, expand the offset calculation and to the compare on the offset if profitable. This came up in SmallVector code. llvm-svn: 150962
* Add r149110 back with a fix for when the vector and the int have the sameRafael Espindola2012-01-271-6/+5
| | | | | | width. llvm-svn: 149151
* Revert r149110 and add a testcase that was crashing since that revision.Rafael Espindola2012-01-271-2/+12
| | | | | | | Unfortunately I also had to disable constant-pool-sharing.ll the code it tests has been updated to use the IL logic. llvm-svn: 149148
* enhance constant folding to be able to constant fold bitcast of Chris Lattner2012-01-271-2/+2
| | | | | | ConstantVector's to integer type. llvm-svn: 149110
* FileCheck hygiene.Benjamin Kramer2012-01-051-1/+1
| | | | llvm-svn: 147580
* Improved fix for abs(val) != 0 to check other similar case. Also fixed ↵Pete Cooper2011-12-011-2/+12
| | | | | | style issues and confusing comment llvm-svn: 145618
* Removed use of grep from test and moved it to be with other icmp testsPete Cooper2011-12-011-0/+11
| | | | llvm-svn: 145570
* PR10267: Don't combine an equality compare with an AND into an inequality ↵Benjamin Kramer2011-07-041-0/+12
| | | | | | | | compare when the AND has more than one use. This can pessimize code, inequalities are generally more expensive. llvm-svn: 134379
* InstCombine: Fold A-b == C --> b == A-C if A and C are constants.Benjamin Kramer2011-06-131-0/+16
| | | | | | The backend already knew this trick. llvm-svn: 132915
* InstCombine: Shrink ((zext X) & C1) == C2 to fold away the cast if the ↵Benjamin Kramer2011-06-121-0/+10
| | | | | | "zext" and the "and" have one use. llvm-svn: 132897
* PR9838: Fix transform introduced in r127064 to not trigger when only one ↵Eli Friedman2011-05-051-0/+11
| | | | | | side of the icmp is an exact shift. llvm-svn: 130954
* Transform: "icmp eq (trunc (lshr(X, cst1)), cst" to "icmp (and X, mask), cst"Chris Lattner2011-04-261-0/+16
| | | | | | | | | | 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. llvm-svn: 130238
* Fix mistyped CHECK lines.Benjamin Kramer2011-03-091-1/+1
| | | | llvm-svn: 127366
OpenPOWER on IntegriCloud