summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ValueTracking, InstCombine] canonicalize fcmp ord/uno with non-NAN ops to ↵Sanjay Patel2017-09-051-15/+6
| | | | | | | | | | | | | | | | | | | | | null constants This is a preliminary step towards solving the remaining part of PR27145 - IR for isfinite(): https://bugs.llvm.org/show_bug.cgi?id=27145 In order to solve that one more generally, we need to add matching for and/or of fcmp ord/uno with a constant operand. But while looking at those patterns, I realized we were missing a canonicalization for nonzero constants. Rather than limiting to just folds for constants, we're adding a general value tracking method for this based on an existing DAG helper. By transforming everything to 0.0, we can simplify the existing code in foldLogicOfFCmps() and pick up missing vector folds. Differential Revision: https://reviews.llvm.org/D37427 llvm-svn: 312591
* [InstCombine] replace unnecessary fcmp fold with assertSanjay Patel2017-09-021-6/+3
| | | | | | See https://reviews.llvm.org/rL312411 for related InstSimplify tests. llvm-svn: 312421
* [InstCombine] combine foldAndOfFCmps and foldOrOfFcmps; NFCISanjay Patel2017-09-021-75/+30
| | | | | | | | In addition to removing chunks of duplicated code, we don't want these to diverge. If there's a fold for one, there should be a fold of the other via DeMorgan's Laws. llvm-svn: 312420
* [InstCombine] fix misnamed locals and use them to reduce code; NFCISanjay Patel2017-09-021-34/+34
| | | | | | | | | We had these locals: Value *Op0RHS = LHS->getOperand(1); Value *Op1LHS = RHS->getOperand(0); ...so we confusingly transposed the meaning of left/right and op0/op1. llvm-svn: 312418
* [InstCombine] remove unnecessary code; NFCSanjay Patel2017-09-021-3/+0
| | | | llvm-svn: 312416
* [InstCombine] move related functions next to each other; NFCSanjay Patel2017-09-021-51/+51
| | | | | | | | This makes it easier to see that they're almost duplicates. As with the similar icmp functions, there should be identical folds for both logic ops because those are DeMorganized variants. llvm-svn: 312415
* [InstCombine] Don't require the compare types to be the same in ↵Craig Topper2017-09-011-3/+2
| | | | | | | | | | getMaskedTypeForICmpPair. A future patch will make the code look through truncates feeding the compare. So the compares might be different types but the pretruncated types might be the same. This should be safe because we still require the same Value* to be used truncated or not in both compares. So that serves to ensure the types are the same. llvm-svn: 312381
* [InstCombine] When converting decomposeBitTestICmp's APInt return to ↵Craig Topper2017-09-011-2/+2
| | | | | | | | ConstantInt, make sure we use the type from the Value* that was also returned from decomposeBitTestICmp. Previously we used the type from the LHS of the compare, but a future patch will change decomposeBitTestICmp to look through truncates so it will return a pretruncated Value* and the type needs to match that. llvm-svn: 312380
* [InstCombine] Remove check for sext of vector icmp from shouldOptimizeCastCraig Topper2017-08-221-6/+0
| | | | | | | | | | | | Looks like for 'and' and 'or' we end up performing at least some of the transformations this is bocking in a round about way anyway. For 'and sext(cmp1), sext(cmp2) we end up later turning it into 'select cmp1, sext(cmp2), 0'. Then we optimize that back to sext (and cmp1, cmp2). This is the same result we would have gotten if shouldOptimizeCast hadn't blocked it. We do something analogous for 'or'. With this patch we allow that transformation to happen directly in foldCastedBitwiseLogic. And we now support the same thing for 'xor'. This is definitely opening up many other cases, but since we already went around it for some cases hopefully it's ok. Differential Revision: https://reviews.llvm.org/D36213 llvm-svn: 311508
* [InstCombine] Move the checks for pointer types in getMaskedTypeForICmpPair ↵Craig Topper2017-08-211-12/+6
| | | | | | | | | | earlier in the function I don't think there's any reason to have them scattered about and on all 4 operands. We already have an early check that both compares must be the same type. And within a given compare the LHS and RHS must have the same type. Beyond that I don't think there's anyway this function returns anything valid for pointer types. So let's just return early and be done with it. Differential Revision: https://reviews.llvm.org/D36561 llvm-svn: 311383
* Recommit r310869, "[InstSimplify][InstCombine] Modify the interface of ↵Craig Topper2017-08-141-3/+15
| | | | | | | | | | | | | | | | | | | | decomposeBitTestICmp and use it in the InstSimplify" This recommits r310869, with the moved files and no extra changes. Original commit message: This addresses a fixme in InstSimplify about using decomposeBitTest. This also fixes InstSimplify to handle ugt and ult compares too. I've modified the interface a little to return only the APInt version of the mask that InstSimplify needs. InstCombine now has a small wrapper routine to create a Constant out of it. I've also dropped the returning of 0 since InstSimplify doesn't need that. So InstCombine creates a zero constant itself. I also had to make decomposeBitTest support vectors since InstSimplify needs that. As InstSimplify can't use something from the Transforms library, I've moved the CmpInstAnalysis code to the Analysis library. Differential Revision: https://reviews.llvm.org/D36593 llvm-svn: 310889
* Revert r310869 "[InstSimplify][InstCombine] Modify the interface of ↵Craig Topper2017-08-141-15/+3
| | | | | | | | decomposeBitTestICmp and use it in the InstSimplify" Failed to add the two files that moved. And then added an extra change I didn't mean to while trying to fix that. Reverting everything. llvm-svn: 310873
* [InstSimplify][InstCombine] Modify the interface of decomposeBitTestICmp and ↵Craig Topper2017-08-141-3/+15
| | | | | | | | | | | | | | | | use it in the InstSimplify This addresses a fixme in InstSimplify about using decomposeBitTest. This also fixes InstSimplify to handle ugt and ult compares too. I've modified the interface a little to return only the APInt version of the mask that InstSimplify needs. InstCombine now has a small wrapper routine to create a Constant out of it. I've also dropped the returning of 0 since InstSimplify doesn't need that. So InstCombine creates a zero constant itself. I also had to make decomposeBitTest support vectors since InstSimplify needs that. As InstSimplify can't use something from the Transforms library, I've moved the CmpInstAnalysis code to the Analysis library. Differential Revision: https://reviews.llvm.org/D36593 llvm-svn: 310869
* [InstCombine] Simplify and inline FoldOrWithConstants/FoldXorWithConstantsCraig Topper2017-08-141-85/+19
| | | | | | | | | | | | | | | | | Summary: These functions were overly complicated. The body of this function was rechecking for an And operation to find the constant, but we already knew we were looking at two Ands ORed together and the pieces are in variables. We already had earlier nearby code that checked for ConstantInts. So just inline the remaining parts into the earlier code. Next step is to use m_APInt instead of ConstantInt. Reviewers: spatel, efriedma, davide, majnemer Reviewed By: spatel Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D36439 llvm-svn: 310806
* [InstCombine] Make (X|C1)^C2 -> X^(C1^C2) iff X&~C1 == 0 work for splat vectorsCraig Topper2017-08-101-23/+18
| | | | | | | | This also corrects the description to match what was actually implemented. The old comment said X^(C1|C2), but it implemented X^((C1|C2)&~(C1&C2)). I believe ((C1|C2)&~(C1&C2)) is equivalent to (C1^C2). Differential Revision: https://reviews.llvm.org/D36505 llvm-svn: 310658
* [InstCombine] Fix a crash in getSelectCondition if we happen to have two ↵Craig Topper2017-08-101-2/+3
| | | | | | | | inverse vectors of i1 constants. We used to try to truncate the constant vector to vXi1, but if it's already i1 this would fail. Instead we now use IRBuilder::getZExtOrTrunc which should check the type and only create a trunc if needed. I believe this should trigger constant folding in the IRBuilder and ultimately do the same thing just with the additional type check. llvm-svn: 310639
* [InstCombine] Use regular dyn_cast instead of a matcher for a simple case. NFCCraig Topper2017-08-091-2/+2
| | | | llvm-svn: 310446
* Removing an unused variable that was missed with the refactoring in r310272; ↵Aaron Ballman2017-08-071-3/+0
| | | | | | NFC. llvm-svn: 310285
* [InstCombine] Support (X | C1) & C2 --> (X & C2^(C1&C2)) | (C1&C2) for ↵Craig Topper2017-08-071-15/+16
| | | | | | | | | | | | vector splats Note the original code I deleted incorrectly listed this as (X | C1) & C2 --> (X & C2^(C1&C2)) | C1 Which is only valid if C1 is a subset of C2. This relied on SimplifyDemandedBits to remove any extra bits from C1 before we got to that code. My new implementation avoids relying on that behavior so that it can be naively verified with alive. Differential Revision: https://reviews.llvm.org/D36384 llvm-svn: 310272
* [InstCombine] Remove shift handling from OptAndOp.Craig Topper2017-08-061-58/+0
| | | | | | | | | | | | | | Summary: This is all handled by SimplifyDemandedBits. Reviewers: spatel, davide Reviewed By: davide Subscribers: davide, llvm-commits Differential Revision: https://reviews.llvm.org/D36382 llvm-svn: 310234
* [InstCombine] Support (X ^ C1) & C2 --> (X & C2) ^ (C1&C2) for vector splats.Craig Topper2017-08-061-8/+10
| | | | llvm-svn: 310233
* [InstCombine] Support '(C - X) ^ signmask -> (C + signmask - X)' and '(X + ↵Craig Topper2017-08-061-16/+11
| | | | | | C) ^ signmask -> (X + C + signmask)' for vector splats. llvm-svn: 310232
* [InstCombine] Support ~(c-X) --> X+(-c-1) and ~(X-c) --> (-c-1)-X for splat ↵Craig Topper2017-08-061-14/+25
| | | | | | vectors. llvm-svn: 310195
* [InstCombine] Fold (C - X) ^ signmask -> (C + signmask - X).Craig Topper2017-08-051-6/+11
| | | | llvm-svn: 310186
* [InstCombine] Remove the (not (sext)) case from foldBoolSextMaskToSelect and ↵Craig Topper2017-08-041-27/+8
| | | | | | | | | | | | | | | | | | | inline the remaining code to match visitOr Summary: The (not (sext)) case is really (xor (sext), -1) which should have been simplified to (sext (xor, 1)) before we got here. So we shouldn't need to handle it. With that taken care of we only need to two cases so don't need the swap anymore. This makes us in sync with the equivalent code in visitOr so inline this to match. Reviewers: spatel, eli.friedman, majnemer Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36240 llvm-svn: 310063
* [InstCombine] Remove explicit code for folding (xor(zext(cmp)), 1) and ↵Craig Topper2017-08-021-15/+0
| | | | | | | | | | (xor(sext(cmp)), -1) to ext(!cmp). As far as I can tell this should be handled by foldCastedBitwiseLogic which is called later in visitXor. Differential Revision: https://reviews.llvm.org/D36214 llvm-svn: 309882
* [InstCombine] Support sext in foldLogicCastConstantCraig Topper2017-08-021-4/+14
| | | | | | | | This adds support for sext in foldLogicCastConstant. This is a prerequisite for D36214. Differential Revision: https://reviews.llvm.org/D36234 llvm-svn: 309880
* [InstCombine] allow mask hoisting transform for vector typesSanjay Patel2017-07-311-33/+27
| | | | llvm-svn: 309627
* [InstCombine] Move (0 - x) & 1 --> x & 1 to SimplifyDemandedUseBits.Craig Topper2017-07-161-5/+1
| | | | | | This removes a dedicated matcher and allows us to support more than just an AND masking the lower bit. llvm-svn: 308124
* [InstCombine] Improve the expansion in SimplifyUsingDistributiveLaws to ↵Craig Topper2017-07-151-18/+0
| | | | | | | | | | | | | | | | | | | handle cases where one side doesn't simplify, but the other side resolves to an identity value Summary: If one side simplifies to the identity value for inner opcode, we can replace the value with just the operation that can't be simplified. I've removed a couple now unneeded special cases in visitAnd and visitOr. There are probably other cases I missed. Reviewers: spatel, majnemer, hfinkel, dberlin Reviewed By: spatel Subscribers: grandinj, llvm-commits, spatel Differential Revision: https://reviews.llvm.org/D35451 llvm-svn: 308111
* [InstCombine] improve (1 << x) & 1 --> zext(x == 0) foldingSanjay Patel2017-07-151-15/+13
| | | | | | | 1. Add a one-use check to prevent increasing instruction count. 2. Generalize the pattern matching to include vector types. llvm-svn: 308105
* [InstCombine] allow (0 - x) & 1 --> x & 1 for vectorsSanjay Patel2017-07-151-6/+5
| | | | llvm-svn: 308098
* [InstCombine] remove dead code/tests; NFCISanjay Patel2017-07-151-11/+0
| | | | | | | These patterns and tests were added to InstSimplify with: https://reviews.llvm.org/rL303004 llvm-svn: 308096
* [IR] Add Type::isIntOrIntVectorTy(unsigned) similar to the existing ↵Craig Topper2017-07-091-8/+7
| | | | | | isIntegerTy(unsigned), but also works for vectors. llvm-svn: 307492
* [InstCombine] Make InstCombine's IRBuilder be passed by reference everywhereCraig Topper2017-07-071-132/+132
| | | | | | | | Previously the InstCombiner class contained a pointer to an IR builder that had been passed to the constructor. Sometimes this would be passed to helper functions as either a pointer or the pointer would be dereferenced to be passed by reference. This patch makes it a reference everywhere including the InstCombiner class itself so there is more inconsistency. This a large, but mechanical patch. I've done very minimal formatting changes on it despite what clang-format wanted to do. llvm-svn: 307451
* [Constants] If we already have a ConstantInt*, prefer to use ↵Craig Topper2017-07-061-3/+3
| | | | | | | | isZero/isOne/isMinusOne instead of isNullValue/isOneValue/isAllOnesValue inherited from Constant. NFCI Going through the Constant methods requires redetermining that the Constant is a ConstantInt and then calling isZero/isOne/isMinusOne. llvm-svn: 307292
* [InstCombine] Change helper method to a file local static method. NFCCraig Topper2017-07-061-4/+5
| | | | llvm-svn: 307275
* [InstCombine] Clarify comment to mention other transform that it does. NFCCraig Topper2017-07-061-1/+2
| | | | llvm-svn: 307274
* [InstCombine] Add single use checks to SimplifyBSwap to ensure we are really ↵Craig Topper2017-07-061-4/+9
| | | | | | | | | | | | saving instructions Bswap isn't a simple operation so we need to make sure we are really removing a call to it before doing these simplifications. For the case when both LHS and RHS are bswaps I've allowed it to be moved if either LHS or RHS has a single use since that at least allows us to move it later where it might find another bswap to combine with and it decreases the use count on the other side so maybe the other user can be optimized. Differential Revision: https://reviews.llvm.org/D34974 llvm-svn: 307273
* [InstCombine] Use CmpInst::Predicate with m_Cmp instead of ↵Craig Topper2017-07-051-1/+1
| | | | | | | | ICmpInst::Predicate. NFC There isn't really an ICmpInst version so we're just accessing the CmpInst version through inheritance. llvm-svn: 307199
* [InstCombine] Add a TODO for a probable missing single use check. NFCCraig Topper2017-07-031-0/+2
| | | | | | Will try to fix it soon, but in case I forget. llvm-svn: 307003
* [InstCombine] Support BITWISE_OP( BSWAP(x), CONSTANT ) -> BSWAP( ↵Craig Topper2017-07-031-18/+12
| | | | | | BITWISE_OP(x, BSWAP(CONSTANT) ) ) for splat vectors. llvm-svn: 307002
* [InstCombine] Remove support for BITWISE_OP(CONSTANT, BSWAP(x)) -> ↵Craig Topper2017-07-031-7/+2
| | | | | | | | BSWAP(OP(BSWAP(CONSTANT), x)). Constants were already canonicalized to the right hand side before we got here. llvm-svn: 307000
* [InstCombine] Support BITWISE_OP(BSWAP(A),BSWAP(B))->BSWAP(BITWISE_OP(A, B)) ↵Craig Topper2017-07-031-7/+3
| | | | | | for vectors. llvm-svn: 306999
* [InstCombine] Remove an if that should have been guaranteed by the caller. ↵Craig Topper2017-07-031-4/+2
| | | | | | Replace with an assert. NFC llvm-svn: 306997
* [InstCombine] Fold (a | b) ^ (~a | ~b) --> ~(a ^ b) and (a & b) ^ (~a & ~b) ↵Craig Topper2017-07-021-2/+18
| | | | | | | | | | | | | | | | | | | --> ~(a ^ b) Summary: I came across this while thinking about what would happen if one of the operands in this xor pattern was itself a inverted (A & ~B) ^ (~A & B)-> (A^B). The patterns here assume that the (~a | ~b) will be demorganed to ~(a & b) first. Though I wonder if there's a multiple use case that would prevent the demorgan. Reviewers: spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34870 llvm-svn: 306967
* [InstCombine] In foldXorToXor, move the commutable matcher from the LHS ↵Craig Topper2017-06-301-8/+8
| | | | | | | | | | match to the RHS match. No meaningful change intended. There are two conditions ORed here with similar checks and each contain two matches that must be true for the if to succeed. With the commutable match on the first half of the OR then both ifs basically have the same first part and only the second part distinguishs. With this change we move the commutable match to second half and make the first half unique. This caused some tests to change because we now produce a commuted result, but this shouldn't matter in practice. llvm-svn: 306800
* [InstCombine] In visitXor, use m_Not on the instruction itself instead of ↵Craig Topper2017-06-291-3/+2
| | | | | | looking for all ones in Op1. This is consistent with 3 other not checks before this one. NFCI llvm-svn: 306617
* [InstCombine] Add one use checks to or/and->xnor foldingCraig Topper2017-06-221-6/+8
| | | | | | | | | | If the components of the and/or had multiple uses, this transform created an additional instruction. This patch makes sure we remove one of the components. Differential Revision: https://reviews.llvm.org/D34498 llvm-svn: 306027
* [InstCombine] reverse bitcast + bitwise-logic canonicalization (PR33138)Sanjay Patel2017-06-221-16/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 2 parts to this patch made simultaneously to avoid a regression. We're reversing the canonicalization that moves bitwise vector ops before bitcasts. We're moving bitwise vector ops *after* bitcasts instead. That's the 1st and 3rd hunks of the patch. The motivation is that there's only one fold that currently depends on the existing canonicalization (see next), but there are many folds that would automatically benefit from the new canonicalization. PR33138 ( https://bugs.llvm.org/show_bug.cgi?id=33138 ) shows why/how we have these patterns in IR. There's an or(and,andn) pattern that requires an adjustment in order to continue matching to 'select' because the bitcast changes position. This match is unfortunately complicated because it requires 4 logic ops with optional bitcast and sext ops. Test diffs: 1. The bitcast.ll and bitcast-bigendian.ll changes show the most basic difference - bitcast comes before logic. 2. There are also tests with no diffs in bitcast.ll that verify that we're still doing folds that were enabled by the previous canonicalization. 3. icmp-xor-signbit.ll shows the payoff. We don't need to adjust existing icmp patterns to look through bitcasts. 4. logical-select.ll contains several tests for the or(and,andn) --> select fold to verify that we are still handling those cases. The lone diff shows the movement of the bitcast from the new canonicalization rule. Differential Revision: https://reviews.llvm.org/D33517 llvm-svn: 306011
OpenPOWER on IntegriCloud