summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine
Commit message (Collapse)AuthorAgeFilesLines
...
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-111-8/+7
| | | | | | No functionality change is intended. llvm-svn: 278417
* Fix some Clang-tidy modernize and Include What You Use warnings.Eugene Zelenko2016-08-111-11/+39
| | | | | | Differential revision: https://reviews.llvm.org/D23291 llvm-svn: 278364
* fix comment; NFCSanjay Patel2016-08-111-2/+3
| | | | llvm-svn: 278342
* use auto* with dyn_cast ; NFCSanjay Patel2016-08-111-2/+1
| | | | llvm-svn: 278340
* getParent()->getParent() == getFunction() ; NFCSanjay Patel2016-08-111-2/+1
| | | | llvm-svn: 278339
* Consistently use FunctionAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
* InstCombine: Remove a redundant #ifdef NDEBUG. NFCJustin Bogner2016-08-081-2/+0
| | | | | | The DEBUG() macro already does this. llvm-svn: 278049
* [JumpThreading] Fix handling of aliasing metadata.Eli Friedman2016-08-081-2/+1
| | | | | | | | | | | | | | | | | | Summary: The correctness fix here is that when we CSE a load with another load, we need to combine the metadata on the two loads. This matches the behavior of other passes, like instcombine and GVN. There's also a minor optimization improvement here: for load PRE, the aliasing metadata on the inserted load should be the same as the metadata on the original load. Not sure why the old code was throwing it away. Issue found by inspection. Differential Revision: http://reviews.llvm.org/D21460 llvm-svn: 277977
* [InstCombine] Infer inbounds on geps of allocasDavid Majnemer2016-08-071-0/+19
| | | | llvm-svn: 277950
* [InstCombine] Don't coerce non-integral pointers to integersSanjoy Das2016-08-061-1/+2
| | | | | | | | | | Reviewers: majnemer Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D23231 llvm-svn: 277910
* [InstCombine] refactor ctlz/cttz folds (NFCI)Sanjay Patel2016-08-051-34/+33
| | | | | | | | | | Note that this fold really belongs in InstSimplify. Refactoring here anyway as an intermediate step because there's a planned addition to this function in D23134. Differential Revision: https://reviews.llvm.org/D23223 llvm-svn: 277883
* [InstCombine] try to fold (select C, (sext A), B) into logical opsNicolai Haehnle2016-08-052-1/+57
| | | | | | | | | | | | | | | | | | | | | | Summary: Turn (select C, (sext A), B) into (sext (select C, A, B')) when A is i1 and B is a compatible constant, also for zext instead of sext. This will then be further folded into logical operations. The transformation would be valid for non-i1 types as well, but other parts of InstCombine prefer to have sext from non-i1 as an operand of select. Motivated by the shader compiler frontend in Mesa for AMDGPU, which emits i32 for boolean operations. With this change, the boolean logic is fully recovered. Reviewers: majnemer, spatel, tstellarAMD Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22747 llvm-svn: 277801
* InstCombine: Clean up some trailing whitespace. NFCJustin Bogner2016-08-054-13/+13
| | | | llvm-svn: 277793
* InstCombine: Replace some never-null pointers with references. NFCJustin Bogner2016-08-0513-104/+102
| | | | llvm-svn: 277792
* IR: Provide an IRBuilder Inserter that calls a callback after insertionJustin Bogner2016-08-042-25/+10
| | | | | | | | | | Add a generalized IRBuilderCallbackInserter, which is just given a callback to execute after insertion. This can be used to get rid of the custom inserter in InstCombine, which will in turn allow me to add target specific InstCombineCalls API for intrinsics without horrible layering violations. llvm-svn: 277784
* [InstCombine] use m_APInt to allow icmp eq (mul X, C1), C2 folds for splat ↵Sanjay Patel2016-08-041-6/+5
| | | | | | | | | | | | | | | | constant vectors This concludes the splat vector enhancements for foldICmpEqualityWithConstant(). Other commits in this series: https://reviews.llvm.org/rL277762 https://reviews.llvm.org/rL277752 https://reviews.llvm.org/rL277738 https://reviews.llvm.org/rL277731 https://reviews.llvm.org/rL277659 https://reviews.llvm.org/rL277638 https://reviews.llvm.org/rL277629 llvm-svn: 277779
* [InstCombine] use m_APInt to allow icmp eq (and X, C1), C2 folds for splat ↵Sanjay Patel2016-08-041-14/+9
| | | | | | constant vectors llvm-svn: 277762
* [InstCombine] use m_APInt to allow icmp eq (or X, C1), C2 folds for splat ↵Sanjay Patel2016-08-041-9/+7
| | | | | | constant vectors llvm-svn: 277752
* [InstCombine] use m_APInt to allow icmp eq (op X, Y), C folds for splat ↵Sanjay Patel2016-08-041-11/+0
| | | | | | | | | constant vectors I'm removing a misplaced pair of more specific folds from InstCombine in this patch as well, so we know where those folds are happening in InstSimplify. llvm-svn: 277738
* [InstCombine] use m_APInt to allow icmp eq (sub C1, X), C2 folds for splat ↵Sanjay Patel2016-08-041-4/+4
| | | | | | constant vectors llvm-svn: 277731
* Add popcount(n) == bitsize(n) -> n == -1 transformation.Amaury Sechet2016-08-041-4/+10
| | | | | | | | | | | | Summary: As per title. Reviewers: majnemer, spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23139 llvm-svn: 277694
* [InstCombine] use m_APInt to allow icmp eq (add X, C1), C2 folds for splat ↵Sanjay Patel2016-08-031-6/+8
| | | | | | constant vectors llvm-svn: 277659
* [InstCombine] use m_APInt to allow icmp eq (srem X, C1), C2 folds for splat ↵Sanjay Patel2016-08-031-4/+3
| | | | | | constant vectors llvm-svn: 277638
* [InstCombine] Refactor optimization of zext(or(icmp, icmp)) to enable more ↵Tobias Grosser2016-08-032-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | aggressive cast-folding Summary: InstCombine unfolds expressions of the form `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` such that in a later iteration of InstCombine the exposed `zext(icmp)` instructions can be optimized. We now combine this unfolding and the subsequent `zext(icmp)` optimization to be performed together. Since the unfolding doesn't happen separately anymore, we also again enable the folding of `logic(cast(icmp), cast(icmp))` expressions to `cast(logic(icmp, icmp))` which had been disabled due to its interference with the unfolding transformation. Tested via `make check` and `lnt`. Background ========== For a better understanding on how it came to this change we subsequently summarize its history. In commit r275989 we've already tried to enable the folding of `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))` which had to be reverted in r276106 because it could lead to an endless loop in InstCombine (also see http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160718/374347.html). The root of this problem is that in `visitZExt()` in InstCombineCasts.cpp there also exists a reverse of the above folding transformation, that unfolds `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` in order to expose `zext(icmp)` operations which would then possibly be eliminated by subsequent iterations of InstCombine. However, before these `zext(icmp)` would be eliminated the folding from r275989 could kick in and cause InstCombine to endlessly switch back and forth between the folding and the unfolding transformation. This is the reason why we now combine the `zext`-unfolding and the elimination of the exposed `zext(icmp)` to happen at one go because this enables us to still allow the cast-folding in `logic(cast(icmp), cast(icmp))` without entering an endless loop again. Details on the submitted changes ================================ - In `visitZExt()` we combine the unfolding and optimization of `zext` instructions. - In `transformZExtICmp()` we have to use `Builder->CreateIntCast()` instead of `CastInst::CreateIntegerCast()` to make sure that the new `CastInst` is inserted in a `BasicBlock`. The new calls to `transformZExtICmp()` that we introduce in `visitZExt()` would otherwise cause according assertions to be triggered (in our case this happend, for example, with lnt for the MultiSource/Applications/sqlite3 and SingleSource/Regression/C++/EH/recursive-throw tests). The subsequent usage of `replaceInstUsesWith()` is necessary to ensure that the new `CastInst` replaces the `ZExtInst` accordingly. - In InstCombineAndOrXor.cpp we again allow the folding of casts on `icmp` instructions. - The instruction order in the optimized IR for the zext-or-icmp.ll test case is different with the introduced changes. - The test cases in zext.ll have been adopted from the reverted commits r275989 and r276105. Reviewers: grosser, majnemer, spatel Subscribers: eli.friedman, majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D22864 Contributed-by: Matthias Reisinger <d412vv1n@gmail.com> llvm-svn: 277635
* [InstCombine] use m_APInt to allow icmp (binop X, Y), C folds with constant ↵Sanjay Patel2016-08-031-14/+20
| | | | | | | | | splat vectors This removes the restriction for the icmp constant, but as noted by the FIXME comments, we still need to change individual checks for binop operand constants. llvm-svn: 277629
* use local variables; NFCSanjay Patel2016-08-031-29/+23
| | | | llvm-svn: 277612
* [InstCombine] replace dyn_casts with matches; NFCISanjay Patel2016-08-022-15/+15
| | | | | | Clean-up before changing this to allow folds for vectors. llvm-svn: 277538
* [ConstnatFolding] Teach the folder how to fold ConstantVectorDavid Majnemer2016-07-293-12/+13
| | | | | | | | | | | A ConstantVector can have ConstantExpr operands and vice versa. However, the folder had no ability to fold ConstantVectors which, in some cases, was an optimization barrier. Instead, rephrase the folder in terms of Constants instead of ConstantExprs and teach callers how to deal with failure. llvm-svn: 277099
* Do not remove empty lifetime.start/lifetime.end rangesVitaly Buka2016-07-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: Asan stack-use-after-scope check should poison alloca even if there is no access between start and end. This is possible for code like this: for (int i = 0; i < 3; i++) { int x; p = &x; } "Loop Invariant Code Motion" will move "p = &x;" out of the loop, making start/end range empty. PR27453 Reviewers: eugenis Differential Revision: https://reviews.llvm.org/D22842 llvm-svn: 277072
* Should be committed as one CL.Vitaly Buka2016-07-281-5/+0
| | | | | | This reverts commits r277068 r277067 r277066. llvm-svn: 277071
* Do not remove empty lifetime.start/lifetime.end rangesVitaly Buka2016-07-281-8/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: Asan stack-use-after-scope check should poison alloca even if there is no access between start and end. This is possible for code like this: for (int i = 0; i < 3; i++) { int x; p = &x; } "Loop Invariant Code Motion" will move "p = &x;" out of the loop, making start/end range empty. PR27453 Reviewers: eugenis Differential Revision: https://reviews.llvm.org/D22842 llvm-svn: 277068
* manedVitaly Buka2016-07-281-6/+8
| | | | llvm-svn: 277067
* rangeVitaly Buka2016-07-281-0/+6
| | | | llvm-svn: 277066
* [InstCombine] Handle failures from ConstantFoldConstantExpressionDavid Majnemer2016-07-281-1/+2
| | | | | | | | ConstantFoldConstantExpression returns null when folding fails. This fixes PR28745. llvm-svn: 276952
* [InstCombine] allow icmp (bit-manipulation-intrinsic(), C) folds for vectorsSanjay Patel2016-07-232-15/+17
| | | | llvm-svn: 276523
* [InstCombine] move udiv+cmp fold over with other BinOp+cmp folds; NFCISanjay Patel2016-07-231-9/+8
| | | | llvm-svn: 276502
* Don't remove side effecting instructions due to ConstantFoldInstructionDavid Majnemer2016-07-221-3/+6
| | | | | | | | | Just because we can constant fold the result of an instruction does not imply that we can delete the instruction. It may have side effects. This fixes PR28655. llvm-svn: 276389
* [InstCombine] break up foldICmpEqualityWithConstant(); NFCISanjay Patel2016-07-212-148/+161
| | | | | | | Almost all of these folds require changes to allow vector types. Splitting up the logic should make that easier to do incrementally. llvm-svn: 276360
* make InstCombine compare helper functions private; NFCSanjay Patel2016-07-212-68/+69
| | | | | | Also, rename some of them for consistency and to follow current conventions. llvm-svn: 276312
* [InstCombine] break up visitICmpInstWithInstAndIntCst(); NFCISanjay Patel2016-07-212-155/+166
| | | | | | | 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
* [InstCombine] LogicOpc (zext X), C --> zext (LogicOpc X, C) (PR28476)Sanjay Patel2016-07-212-28/+16
| | | | | | | | | | | | | | | | The benefits of this change include: 1. Remove DeMorgan-matching code that was added specifically to work-around the missing transform in http://reviews.llvm.org/rL248634. 2. Makes the DeMorgan transform work for vectors too. 3. Fix PR28476: https://llvm.org/bugs/show_bug.cgi?id=28476 Extending this transform to other casts and other associative operators may be useful too. See https://reviews.llvm.org/D22421 for a prerequisite for doing that though. Differential Revision: https://reviews.llvm.org/D22271 llvm-svn: 276221
* [InstSimplify][InstCombine] don't crash when folding vector selects of icmpSanjay Patel2016-07-201-1/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D22602 llvm-svn: 276209
* move decomposeBitTestICmp() to Transforms/Utils; NFCSanjay Patel2016-07-201-47/+0
| | | | | | | | As noted in https://reviews.llvm.org/D22537 , we can use this functionality in visitSelectInstWithICmp() and InstSimplify, but currently we have duplicated code. llvm-svn: 276140
* Revert "[InstCombine] Enable cast-folding in logic(cast(icmp), cast(icmp))"Benjamin Kramer2016-07-201-8/+2
| | | | | | | | Makes InstCombine infloop when compiling v8. This reverts commit r275989 and r276105. llvm-svn: 276106
* [InstCombine] fold add(zext(xor X, C), C) --> sext X when C is INT_MIN in ↵Sanjay Patel2016-07-191-0/+10
| | | | | | | | | | | | | | | | | | | the source type The pattern may look more obviously like a sext if written as: define i32 @g(i16 %x) { %zext = zext i16 %x to i32 %xor = xor i32 %zext, 32768 %add = add i32 %xor, -32768 ret i32 %add } We already have that fold in visitAdd(). Differential Revision: https://reviews.llvm.org/D22477 llvm-svn: 276035
* [InstCombine] Enable cast-folding in logic(cast(icmp), cast(icmp))Tobias Grosser2016-07-191-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, InstCombine is already able to fold expressions of the form `logic(cast(A), cast(B))` to the simpler form `cast(logic(A, B))`, where logic designates one of `and`/`or`/`xor`. This transformation is implemented in `foldCastedBitwiseLogic()` in InstCombineAndOrXor.cpp. However, this optimization will not be performed if both `A` and `B` are `icmp` instructions. The decision to preclude casts of `icmp` instructions originates in r48715 in combination with r261707, and can be best understood by the title of the former one: > Transform (zext (or (icmp), (icmp))) to (or (zext (cimp), (zext icmp))) if at least one of the (zext icmp) can be transformed to eliminate an icmp. Apparently, it introduced a transformation that is a reverse of the transformation that is done in `foldCastedBitwiseLogic()`. Its purpose is to expose pairs of `zext icmp` that would subsequently be optimized by `transformZExtICmp()` in InstCombineCasts.cpp. Therefore, in order to avoid an endless loop of switching back and forth between these two transformations, the one in `foldCastedBitwiseLogic()` has been restricted to exclude `icmp` instructions which is mirrored in the responsible check: `if ((!isa<ICmpInst>(Cast0Src) || !isa<ICmpInst>(Cast1Src)) && ...` This check seems to sort out more cases than necessary because: - the reverse transformation is obviously done for `or` instructions only - and also not every `zext icmp` pair is necessarily the result of this reverse transformation Therefore we now remove this check and replace it by a more finegrained one in `shouldOptimizeCast()` that now rejects only those `logic(zext(icmp), zext(icmp))` that would be able to be optimized by `transformZExtICmp()`, which also avoids the mentioned endless loop. That means we are now able to also simplify expressions of the form `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))` (`cast` being an arbitrary `CastInst`). As an example, consider the following IR snippet ``` %1 = icmp sgt i64 %a, %b %2 = zext i1 %1 to i8 %3 = icmp slt i64 %a, %c %4 = zext i1 %3 to i8 %5 = and i8 %2, %4 ``` which would now be transformed to ``` %1 = icmp sgt i64 %a, %b %2 = icmp slt i64 %a, %c %3 = and i1 %1, %2 %4 = zext i1 %3 to i8 ``` This issue became apparent when experimenting with the programming language Julia, which makes use of LLVM. Currently, Julia lowers its `Bool` datatype to LLVM's `i8` (also see https://github.com/JuliaLang/julia/pull/17225). In fact, the above IR example is the lowered form of the Julia snippet `(a > b) & (a < c)`. Like shown above, this may introduce `zext` operations, casting between `i1` and `i8`, which could for example hinder ScalarEvolution and Polly on certain code. Reviewers: grosser, vtjnash, majnemer Subscribers: majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D22511 Contributed-by: Matthias Reisinger llvm-svn: 275989
* [InstCombine] Minor cleanup of cast simplification code [NFC]Tobias Grosser2016-07-193-60/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch cleans up parts of InstCombine to raise its compliance with the LLVM coding standards and to increase its readability. The changes and according rationale are summarized in the following: - Rename `ShouldOptimizeCast()` to `shouldOptimizeCast()` since functions should start with a lower case letter. - Move `shouldOptimizeCast()` from InstCombineCasts.cpp to InstCombineAndOrXor.cpp since it's only used there. - Simplify interface of `shouldOptimizeCast()`. - Minor code style adaptions in `shouldOptimizeCast()`. - Remove the documentation on the function definition of `shouldOptimizeCast()` since it just repeats the documentation on its declaration. Also enhance the documentation on its declaration with more information describing its intended use and make it doxygen-compliant. - Change a comment in `foldCastedBitwiseLogic()` from `fold (logic (cast A), (cast B)) -> (cast (logic A, B))` to `fold logic(cast(A), cast(B)) -> cast(logic(A, B))` since the surrounding comments use this format. - Remove comment `Only do this if the casts both really cause code to be generated.` in `foldCastedBitwiseLogic()` since it just repeats parts of the documentation of `shouldOptimizeCast()` and does not help to improve readability. - Simplify the interface of `isEliminableCastPair()`. - Removed the documentation on the function definition of `isEliminableCastPair()` which only contained obvious statements about its implementation. Instead added more general doxygen-compliant documentation to its declaration. - Renamed parameter `DoXform` of `transformZExtIcmp()` to `DoTransform` to make its intention clearer. - Moved documentation of `transformZExtIcmp()` from its definition to its declaration and made it doxygen-compliant. Reviewers: vtjnash, grosser Subscribers: majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D22449 Contributed-by: Matthias Reisinger llvm-svn: 275964
* [InstCombine] allow X + signbit --> X ^ signbit for vector splatsSanjay Patel2016-07-161-3/+10
| | | | llvm-svn: 275691
* [InstCombine] reassociate logic ops with constants separated by a zextSanjay Patel2016-07-161-0/+49
| | | | | | | | | | | | This is a partial implementation of a general fold for associative+commutative operators: (op (cast (op X, C2)), C1) --> (cast (op X, op (C1, C2))) (op (cast (op X, C2)), C1) --> (op (cast X), op (C1, C2)) There are 7 associative operators and 13 cast types, so this could potentially go a lot further. Differential Revision: https://reviews.llvm.org/D22421 llvm-svn: 275684
* don't repeat function names in comments; NFCSanjay Patel2016-07-141-29/+28
| | | | llvm-svn: 275470
OpenPOWER on IntegriCloud