summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] break up visitICmpInstWithInstAndIntCst(); NFCISanjay Patel2016-07-211-155/+164
| | | | | | | Making smaller pieces out of some of these ~1000 line functions should make it easier to incrementally upgrade them to handle vector types. llvm-svn: 276304
* Avoid copies of std::strings and APInt/APFloats where we only read from itBenjamin Kramer2016-06-081-6/+6
| | | | | | | | As suggested by clang-tidy's performance-unnecessary-copy-initialization. This can easily hit lifetime issues, so I audited every change and ran the tests under asan, which came back clean. llvm-svn: 272126
* [InstCombine] limit icmp transform to ConstantInt (PR28011)Sanjay Patel2016-06-061-3/+5
| | | | | | | | | | | | | | | In r271810 ( http://reviews.llvm.org/rL271810 ), I loosened the check above this to work for any Constant rather than ConstantInt. AFAICT, that part makes sense if we can determine that the shrunken/extended constant remained equal. But it doesn't make sense for this later transform where we assume that the constant DID change. This could assert for a ConstantExpr: https://llvm.org/bugs/show_bug.cgi?id=28011 And it could be wrong for a vector as shown in the added regression test. llvm-svn: 271908
* [InstCombine] allow vector icmp bool transformsSanjay Patel2016-06-051-1/+1
| | | | llvm-svn: 271843
* fix documentation comments and other clean-ups; NFCSanjay Patel2016-06-051-74/+67
| | | | llvm-svn: 271839
* [InstCombine] less 'CI' confusion; NFCSanjay Patel2016-06-051-26/+26
| | | | | | | | | Change the name of the ICmpInst to 'ICmp' and the Constant (was a ConstantInt) to 'C', so that it's hopefully clearer that 'CI' refers to CastInst in this context. While we're scrubbing, fix the documentation comment and use 'auto' with 'dyn_cast'. llvm-svn: 271817
* [InstCombine] allow vector constants for cast+icmp foldSanjay Patel2016-06-041-1/+1
| | | | | | | This is step 1 of unknown towards fixing PR28001: https://llvm.org/bugs/show_bug.cgi?id=28001 llvm-svn: 271810
* clean-up; NFCSanjay Patel2016-06-041-4/+3
| | | | llvm-svn: 271807
* fix formatting, punctuation; NFCSanjay Patel2016-06-041-5/+3
| | | | llvm-svn: 271804
* [InstCombine] add another test for wrong icmp constant (PR27792)Sanjay Patel2016-05-171-1/+1
| | | | | | It doesn't matter if the comparison is unsigned; the inc/dec is always signed. llvm-svn: 269831
* [InstCombine] fix constant to be signed for signed comparisonsSanjay Patel2016-05-171-1/+1
| | | | | | | This bug was introduced in r269728 and is the likely cause of many stage 2 ubsan bot failures. I'll add a test in a follow-up commit assuming this fixes things properly. llvm-svn: 269797
* [InstCombine] Don't crash when trying to take an element of a ConstantExpr.Benjamin Kramer2016-05-171-0/+3
| | | | | | Fixes PR27786. llvm-svn: 269757
* try to avoid unused variable warning in release build; NFCISanjay Patel2016-05-171-1/+2
| | | | llvm-svn: 269729
* [InstCombine] check vector elements before trying to transform LE/GE vector ↵Sanjay Patel2016-05-171-78/+42
| | | | | | | | | | | | | | | | | icmp (PR27756) Fix a bug introduced with rL269426 : [InstCombine] canonicalize* LE/GE vector integer comparisons to LT/GT (PR26701, PR26819) We were assuming that a ConstantDataVector / ConstantVector / ConstantAggregateZero operand of an ICMP was composed of ConstantInt elements, but it might have ConstantExpr or UndefValue elements. Handle those appropriately. Also, refactor this function to join the scalar and vector paths and eliminate the switches. Differential Revision: http://reviews.llvm.org/D20289 llvm-svn: 269728
* [InstCombine] handle zero constant vectors for LE/GE comparisons tooSanjay Patel2016-05-131-2/+3
| | | | | | | | | | | | Enhancement to: http://reviews.llvm.org/rL269426 With discussion in: http://reviews.llvm.org/D17859 This should complete the fixes for: PR26701, PR26819: https://llvm.org/bugs/show_bug.cgi?id=26701 https://llvm.org/bugs/show_bug.cgi?id=26819 llvm-svn: 269439
* [InstCombine] canonicalize* LE/GE vector integer comparisons to LT/GT ↵Sanjay Patel2016-05-131-2/+55
| | | | | | | | | | | | | | | (PR26701, PR26819) *We don't currently handle the edge case constants (min/max values), so it's not a complete canonicalization. To fully solve the motivating bugs, we need to enhance this to recognize a zero vector too because that's a ConstantAggregateZero which is a ConstantData, not a ConstantVector or a ConstantDataVector. Differential Revision: http://reviews.llvm.org/D17859 llvm-svn: 269426
* [InstCombine] Fold icmp ugt/ult (udiv i32 C2, X), C1.Chad Rosier2016-05-101-3/+21
| | | | | | | | | | This patch adds support for two optimizations: icmp ugt (udiv C2, X), C1 -> icmp ule X, C2/(C1+1) icmp ult (udiv C2, X), C1 -> icmp ugt X, C2/C1 Differential Revision: http://reviews.llvm.org/D20123 llvm-svn: 269109
* [InstCombine] Fold icmp eq/ne (udiv i32 A, B), 0 -> icmp ugt/ule B, A.Chad Rosier2016-05-091-0/+12
| | | | | | Differential Revision: http://reviews.llvm.org/D20036 llvm-svn: 268960
* "Reapply r268521 "[InstCombine] Canonicalize icmp instructions based on ↵Balaram Makam2016-05-041-0/+45
| | | | | | | | | dominating conditions."" This reapplies commit r268521, that was reverted in r268530 due to a test failure in select-implied.ll Modified the test case to reflect the new change. llvm-svn: 268557
* Revert "[InstCombine] Canonicalize icmp instructions based on dominating ↵Balaram Makam2016-05-041-45/+0
| | | | | | | | conditions." This reverts commit 573a40f79b35cf3e71db331bb00f6a84f03b835d. llvm-svn: 268530
* [InstCombine] Canonicalize icmp instructions based on dominating conditions.Balaram Makam2016-05-041-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch canonicalizes conditions based on the constant range information of the dominating branch condition. For example: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp sgt i64 %a, 0 Would now be canonicalized into: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp ne i64 %a, 0 Reviewers: mcrosier, gberry, t.p.northover, llvm-commits, reames, hfinkel, sanjoy, majnemer Subscribers: MatzeB, majnemer, mcrosier Differential Revision: http://reviews.llvm.org/D18841 llvm-svn: 268521
* [InstCombine] add helper function for ICmp with constant canonicalization; NFCISanjay Patel2016-04-291-24/+38
| | | | | | | As suggested in http://reviews.llvm.org/D17859 , we should enhance this to support vectors. llvm-svn: 268059
* [ValueTracking, VectorUtils] Refactor getIntrinsicIDForCallDavid Majnemer2016-04-191-1/+1
| | | | | | | | | | | | | The functionality contained within getIntrinsicIDForCall is two-fold: it checks if a CallInst's callee is a vectorizable intrinsic. If it isn't an intrinsic, it attempts to map the call's target to a suitable intrinsic. Move the mapping functionality into getIntrinsicForCallSite and rename getIntrinsicIDForCall to getVectorIntrinsicIDForCall while reimplementing it in terms of getIntrinsicForCallSite. llvm-svn: 266801
* [NFC] Header cleanupMehdi Amini2016-04-181-3/+2
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* [InstCombine] Don't transform compares of calls to functions named fabs{f,l,}David Majnemer2016-04-151-30/+25
| | | | | | | | InstCombine wants to optimize compares of calls to fabs with zero. However, we didn't have the necessary legality checking to verify that the function call had the same behavior as fabs. llvm-svn: 266452
* [InstCombine] remove constant by inverting compare + logic (PR27105)Sanjay Patel2016-04-141-0/+9
| | | | | | | | | | | | | | | https://llvm.org/bugs/show_bug.cgi?id=27105 We can check if all bits outside of a constant mask are set with a single constant. As noted in the bug report, although this form should be considered the canonical IR, backends may want to transform this into an 'andn' / 'andc' comparison against zero because that could be a single machine instruction. Differential Revision: http://reviews.llvm.org/D18842 llvm-svn: 266362
* [InstCombine] We folded an fcmp to an i1 instead of a vector of i1David Majnemer2016-04-131-1/+1
| | | | | | | | | Remove an ad-hoc transform in InstCombine and replace it with more general machinery (ValueTracking, InstructionSimplify and VectorUtils). This fixes PR27332. llvm-svn: 266175
* [InstCombine] Don't insert instructions before a catch switchDavid Majnemer2016-03-191-0/+3
| | | | | | | | | CatchSwitches are not splittable, we cannot insert casts, etc. before them. This fixes PR26992. llvm-svn: 263874
* [ValueTracking] Extract isKnownPositive [NFCI]Philip Reames2016-03-091-2/+2
| | | | | | Extract out a generic interface from a recently landed patch and document a TODO in case compile time becomes a problem. llvm-svn: 263062
* [InstCombine] (icmp sgt smin(PosA, B) 0) -> (icmp sgt B 0)Philip Reames2016-03-091-0/+13
| | | | | | | | When checking whether an smin is positive, we can move the comparison to one of the inputs if the other is known positive. If the known positive one is the min, then the other can't be negative. If the other is the min, then we compute the min. Differential Revision: http://reviews.llvm.org/D17873 llvm-svn: 263059
* Remove uses of builtin comma operator.Richard Trieu2016-02-181-9/+20
| | | | | | Cleanup for upcoming Clang warning -Wcomma. No functionality change intended. llvm-svn: 261270
* [InstCombine] Don't aggressively replace xor with icmpDavid Majnemer2016-02-121-17/+20
| | | | | | | | | | | | | | | | | | For some cases, InstCombine replaces the sequence of xor/sub instruction followed by cmp instruction into a single cmp instruction. However, this replacement may result suboptimal result especially when the xor/sub has more than one use, as discussed in bug 26465 (https://llvm.org/bugs/show_bug.cgi?id=26465). This patch make the replacement happen only when xor/sub has only one use. Differential Revision: http://reviews.llvm.org/D16915 Patch by Taewook Oh! llvm-svn: 260695
* function names start with a lowercase letter; NFCSanjay Patel2016-02-011-68/+68
| | | | llvm-svn: 259425
* [InstCombine] Don't transform (X+INT_MAX)>=(Y+INT_MAX) -> (X<=Y)David Majnemer2016-02-011-1/+1
| | | | | | | | | This miscompile came about because we tried to use a transform which was only appropriate for xor operators when addition was present. This fixes PR26407. llvm-svn: 259375
* Re-commit r257064, after it was reverted in r257340.Silviu Baranga2016-01-151-3/+320
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This contains a fix for the issue that caused the revert: we no longer assume that we can insert instructions after the instruction that produces the base pointer. We previously assumed that this would be ok, because the instruction produces a value and therefore is not a terminator. This is false for invoke instructions. We will now insert these new instruction directly at the location of the users. Original commit message: [InstCombine] Look through PHIs, GEPs, IntToPtrs and PtrToInts to expose more constants when comparing GEPs Summary: When comparing two GEP instructions which have the same base pointer and one of them has a constant index, it is possible to only compare indices, transforming it to a compare with a constant. This removes one use for the GEP instruction with the constant index, can reduce register pressure and can sometimes lead to removing the comparisson entirely. InstCombine was already doing this when comparing two GEPs if the base pointers were the same. However, in the case where we have complex pointer arithmetic (GEPs applied to GEPs, PHIs of GEPs, conversions to or from integers, etc) the value of the original base pointer will be hidden to the optimizer and this transformation will be disabled. This change detects when the two sides of the comparison can be expressed as GEPs with the same base pointer, even if they don't appear as such in the IR. The transformation will convert all the pointer arithmetic to arithmetic done on indices and all the relevant uses of GEPs to GEPs with a common base pointer. The GEP comparison will be converted to a comparison done on indices. Reviewers: majnemer, jmolloy Subscribers: hfinkel, jevinskie, jmolloy, aadg, llvm-commits Differential Revision: http://reviews.llvm.org/D15146 llvm-svn: 257897
* Revert r257164 - it has caused spec2k6 failures in LTO modeSilviu Baranga2016-01-111-322/+3
| | | | llvm-svn: 257340
* InstCombineCompares.cpp: Fix a warning. [-Wbraced-scalar-init]NAKAMURA Takumi2016-01-081-1/+1
| | | | llvm-svn: 257167
* Re-commit r257064, this time with a fixed assertSilviu Baranga2016-01-081-3/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In setInsertionPoint if the value is not a PHI, Instruction or Argument it should be a Constant, not a ConstantExpr. Original commit message: [InstCombine] Look through PHIs, GEPs, IntToPtrs and PtrToInts to expose more constants when comparing GEPs Summary: When comparing two GEP instructions which have the same base pointer and one of them has a constant index, it is possible to only compare indices, transforming it to a compare with a constant. This removes one use for the GEP instruction with the constant index, can reduce register pressure and can sometimes lead to removing the comparisson entirely. InstCombine was already doing this when comparing two GEPs if the base pointers were the same. However, in the case where we have complex pointer arithmetic (GEPs applied to GEPs, PHIs of GEPs, conversions to or from integers, etc) the value of the original base pointer will be hidden to the optimizer and this transformation will be disabled. This change detects when the two sides of the comparison can be expressed as GEPs with the same base pointer, even if they don't appear as such in the IR. The transformation will convert all the pointer arithmetic to arithmetic done on indices and all the relevant uses of GEPs to GEPs with a common base pointer. The GEP comparison will be converted to a comparison done on indices. Reviewers: majnemer, jmolloy Subscribers: hfinkel, jevinskie, jmolloy, aadg, llvm-commits Differential Revision: http://reviews.llvm.org/D15146 llvm-svn: 257164
* Revert r257064. It caused failures in some sanitizer tests.Silviu Baranga2016-01-071-322/+3
| | | | llvm-svn: 257069
* Fix build after r257064: we should be returning false, not nullptrSilviu Baranga2016-01-071-2/+2
| | | | llvm-svn: 257067
* [InstCombine] Look through PHIs, GEPs, IntToPtrs and PtrToInts to expose ↵Silviu Baranga2016-01-071-3/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | more constants when comparing GEPs Summary: When comparing two GEP instructions which have the same base pointer and one of them has a constant index, it is possible to only compare indices, transforming it to a compare with a constant. This removes one use for the GEP instruction with the constant index, can reduce register pressure and can sometimes lead to removing the comparisson entirely. InstCombine was already doing this when comparing two GEPs if the base pointers were the same. However, in the case where we have complex pointer arithmetic (GEPs applied to GEPs, PHIs of GEPs, conversions to or from integers, etc) the value of the original base pointer will be hidden to the optimizer and this transformation will be disabled. This change detects when the two sides of the comparison can be expressed as GEPs with the same base pointer, even if they don't appear as such in the IR. The transformation will convert all the pointer arithmetic to arithmetic done on indices and all the relevant uses of GEPs to GEPs with a common base pointer. The GEP comparison will be converted to a comparison done on indices. Reviewers: majnemer, jmolloy Subscribers: hfinkel, jevinskie, jmolloy, aadg, llvm-commits Differential Revision: http://reviews.llvm.org/D15146 llvm-svn: 257064
* getParent() ^ 3 == getModule() ; NFCISanjay Patel2015-12-141-7/+4
| | | | llvm-svn: 255511
* [InstCombine] Optimize icmp of inc/dec at RHSMichael Liao2015-10-191-0/+20
| | | | | | | | | | | | | | | | Allow LLVM to optimize the sequence like the following: %inc = add nsw i32 %i, 1 %cmp = icmp slt %n, %inc into: %cmp = icmp sle i32 %n, %i The case is not handled previously due to the complexity of compuation of %n. Hence, LLVM cannot swap operands of icmp accordingly. llvm-svn: 250746
* InstCombine: Fold comparisons between unguessable allocas and other pointersHans Wennborg2015-10-071-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow us to optimize code such as: int f(int *p) { int x; return p == &x; } as well as: int *allocate(void); int f() { int x; int *p = allocate(); return p == &x; } The folding can only be done under certain circumstances. Even though p and &x cannot alias, the comparison must still return true if the pointer representations are equal. If a user successfully generates a p that's a correct guess for &x, comparison should return true even though p is an invalid pointer. This patch argues that if the address of the alloca isn't observable outside the function, the function can act as-if the address is impossible to guess from the outside. The tricky part is keeping the act consistent: if we fold p == &x to false in one place, we must make sure to fold any other comparisons based on those pointers similarly. To ensure that, we only fold when &x is involved exactly once in comparison instructions. Differential Revision: http://reviews.llvm.org/D13358 llvm-svn: 249490
* Fix Clang-tidy modernize-use-nullptr warnings in source directories and ↵Hans Wennborg2015-10-061-13/+1
| | | | | | | | | | generated files; other minor cleanups. Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13321 llvm-svn: 249482
* [InstCombine] FoldICmpCstShrCst failed for ashr when comparing against -1David Majnemer2015-09-191-1/+1
| | | | | | | | | (icmp eq (ashr C1, %V) -1) may have multiple answers if C1 is not a power of two and has the sign bit set. This fixes PR24873. llvm-svn: 248074
* [InstCombine] FoldICmpCstShrCst didn't handle icmps of -1 in the ashr case ↵David Majnemer2015-09-191-6/+10
| | | | | | correctly llvm-svn: 248073
* [InstCombine] Optimize icmp slt signum(x), 1 --> icmp slt x, 1Sanjoy Das2015-09-161-0/+17
| | | | | | | | | | | | | | | | | | | | | | Summary: `signum(x)` is sometimes implemented as `(x >> 63) | (-x >>> 63)` (for an `i64` `x`). This change adds a matcher for that pattern, and an instcombine rule to optimize `signum(x) s< 1`. Later, we can also consider optimizing: icmp slt signum(x), 0 --> icmp slt x, 0 icmp sle signum(x), 1 --> true etc. Reviewers: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12703 llvm-svn: 247846
* Broaden optimization of fcmp ([us]itofp x, constant) by instcombine.Arch D. Robison2015-09-151-14/+23
| | | | | | | | | | The patch extends the optimization to cases where the constant's magnitude is so small or large that the rounding of the conversion is irrelevant. The "so small" case includes negative zero. Differential review: http://reviews.llvm.org/D11210 llvm-svn: 247708
* [InstCombine] Don't assume m_Mul gives back an InstructionDavid Majnemer2015-09-051-1/+3
| | | | | | This fixes PR24713. llvm-svn: 246933
OpenPOWER on IntegriCloud