summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Fold Select with binary opDavid Bolvansky2018-07-301-0/+33
| | | | | | | | | | | | | | | | | | | | | | | Summary: Fold %A = icmp eq i8 %x, 0 %B = xor i8 %x, %z %C = select i1 %A, i8 %B, i8 %y To %C = select i1 %A, i8 %z, i8 %y Fixes https://bugs.llvm.org/show_bug.cgi?id=38345 Proof: https://rise4fun.com/Alive/43J Reviewers: lebedev.ri, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49954 llvm-svn: 338300
* [InstCombine] canonicalize abs patternChen Zheng2018-07-271-20/+50
| | | | | | Differential Revision: https://reviews.llvm.org/D48754 llvm-svn: 338092
* [InstCombine] add more SPFofSPF foldingChen Zheng2018-07-161-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D49238 llvm-svn: 337143
* [InstCombine] Correct the cmp operand type used when canonicalizing abs/nabsJohn Brawn2018-06-051-1/+1
| | | | | | | | | | When adjusting a cmp in order to canonicalize an abs/nabs select pattern we need to use the type of the existing operand when creating a new operand not the type of a select operand, as the two may be different. This fixes PR37686. llvm-svn: 334019
* [InstCombine] narrow select to match condition operands' sizeSanjay Patel2018-05-311-8/+11
| | | | | | | | | | | | | This is the planned enhancement to D47163 / rL333611. We want to match cmp/select sizes because that will be recognized as min/max more easily and lead to better codegen (especially for vector types). As mentioned in D47163, this improves some of the tests that would also be folded by D46380, so we may want to adjust that patch to match the new patterns where the extend op occurs after the select. llvm-svn: 333689
* [InstCombine] choose 1 form of abs and nabs as canonicalSanjay Patel2018-05-201-0/+51
| | | | | | | | | | | | | | | We already do this for min/max (see the blob above the diff), so we should do the same for abs/nabs. A sign-bit check (<s 0) is used as a predicate for other IR transforms and it's likely the best for codegen. This might solve the motivating cases for D47037 and D47041, but I think those patches still make sense. We can't guarantee this canonicalization if the icmp has more than one use. Differential Revision: https://reviews.llvm.org/D47076 llvm-svn: 332819
* [InstCombine] Qualify a select pattern based transform to restrct to only ↵Craig Topper2018-05-181-1/+1
| | | | | | min/max and ignore abs/nabs. llvm-svn: 332770
* [InstCombine] refine select-of-constants to bitwise opsSanjay Patel2018-05-031-57/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add logic for the special case when a cmp+select can clearly be reduced to just a bitwise logic instruction, and remove an over-reaching chunk of general purpose bit magic. The primary goal is to remove cases where we are not improving the IR instruction count when doing these select transforms, and in all cases here that is true. In the motivating 3-way compare tests, there are further improvements because we can combine/propagate select values (not sure if that belongs in instcombine, but it's there for now). DAGCombiner has folds to turn some of these selects into bit magic, so there should be no difference in the end result in those cases. Not all constant combinations are handled there yet, however, so it is possible that some targets will see more cmov/csel codegen with this change in IR canonicalization. Ideally, we'll go further to *not* turn selects into multiple logic/math ops in instcombine, and we'll canonicalize to selects. But we should make sure that this step does not result in regressions first (and if it does, we should fix those in the backend). The general direction for this change was discussed here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/105373.html http://lists.llvm.org/pipermail/llvm-dev/2017-July/114885.html Alive proofs for the new bit magic: https://rise4fun.com/Alive/XG7 Differential Revision: https://reviews.llvm.org/D46086 llvm-svn: 331486
* [InstCombine] clean up foldSelectICmpAnd(); NFCSanjay Patel2018-04-251-46/+39
| | | | | | | | | | As discussed in D45862, we want to delete parts of this code because it can create more instructions than it removes. But we also want to preserve some folds that are winners, so tidy up what's here to make splitting the good from bad a bit easier. llvm-svn: 330841
* [InstCombine]: foldSelectICmpAndAnd(): and is commutativeRoman Lebedev2018-04-131-24/+20
| | | | | | | | | | | | | | | | | | | | | Summary: The fold added in D45108 did not account for the fact that the and instruction is commutative, and if the mask is a variable, the mask variable and the fold variable may be swapped. I have noticed this by accident when looking into [[ https://bugs.llvm.org/show_bug.cgi?id=6773 | PR6773 ]] This extends/generalizes that fold, so it is handled too. Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45539 llvm-svn: 330001
* [InstCombine] Get rid of select of bittest (PR36950 / PR17564)Roman Lebedev2018-04-071-0/+49
| | | | | | | | | | | | | | | | | | | | Summary: See [[ https://bugs.llvm.org/show_bug.cgi?id=36950 | PR36950 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=17564 | PR17564 ]], D45065, D45107 https://godbolt.org/g/iAYRup Alive proof: https://rise4fun.com/Alive/uiH Testing: `ninja check-llvm` Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45108 llvm-svn: 329492
* [PatternMatch] allow undef elements when matching vector FP +0.0Sanjay Patel2018-03-251-4/+4
| | | | | | | | | | | | | This continues the FP constant pattern matching improvements from: https://reviews.llvm.org/rL327627 https://reviews.llvm.org/rL327339 https://reviews.llvm.org/rL327307 Several integer constant matchers also have this ability. I'm separating matching of integer/pointer null from FP positive zero and renaming/commenting to make the functionality clearer. llvm-svn: 328461
* [InstCombine] canonicalize fcmp+select to fabsSanjay Patel2018-03-191-1/+31
| | | | | | | | | | | | | | This is complicated by -0.0 and nan. This is based on the DAG patterns as shown in D44091. I'm hoping that we can just remove those DAG folds and always rely on IR canonicalization to handle the matching to fabs. We would still need to delete the broken code from DAGCombiner to fix PR36600: https://bugs.llvm.org/show_bug.cgi?id=36600 Differential Revision: https://reviews.llvm.org/D44550 llvm-svn: 327858
* [InstCombine] Replace calls to getNumUses with hasNUses or hasNUsesOrMoreCraig Topper2018-03-121-2/+2
| | | | | | | | | | getNumUses is a linear time operation. It traverses the user linked list to the end and counts as it goes. Since we are only interested in small constant counts, we should use hasNUses or hasNUsesMore more that terminate the traversal as soon as it can provide the answer. There are still two other locations in InstCombine, but changing those would force a rebase of D44266 which if accepted would remove them. Differential Revision: https://reviews.llvm.org/D44398 llvm-svn: 327315
* [InstCombine] simplify min/max canonicalization; NFCISanjay Patel2018-03-061-10/+5
| | | | llvm-svn: 326828
* [ValueTracking] move helpers for SelectPatterns from InstCombine to ↵Sanjay Patel2018-03-061-51/+11
| | | | | | | | | ValueTracking Most of the folds based on SelectPatternResult belong in InstSimplify rather than InstCombine, so the helper code should be available to other passes/analysis. llvm-svn: 326812
* [InstCombine] Don't fold select(C, Z, binop(select(C, X, Y), W)) -> ↵Craig Topper2018-02-141-2/+17
| | | | | | | | | | | | select(C, Z, binop(Y, W)) if the binop is rem or div. The select may have been preventing a division by zero or INT_MIN/-1 so removing it might not be safe. Fixes PR36362. Differential Revision: https://reviews.llvm.org/D43276 llvm-svn: 325148
* [InstCombine] add unsigned saturation subtraction canonicalizationsSanjay Patel2018-02-051-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | This is the instcombine part of unsigned saturation canonicalization. Backend patches already commited: https://reviews.llvm.org/D37510 https://reviews.llvm.org/D37534 It converts unsigned saturated subtraction patterns to forms recognized by the backend: (a > b) ? a - b : 0 -> ((a > b) ? a : b) - b) (b < a) ? a - b : 0 -> ((a > b) ? a : b) - b) (b > a) ? 0 : a - b -> ((a > b) ? a : b) - b) (a < b) ? 0 : a - b -> ((a > b) ? a : b) - b) ((a > b) ? b - a : 0) -> - ((a > b) ? a : b) - b) ((b < a) ? b - a : 0) -> - ((a > b) ? a : b) - b) ((b > a) ? 0 : b - a) -> - ((a > b) ? a : b) - b) ((a < b) ? 0 : b - a) -> - ((a > b) ? a : b) - b) Patch by Yulia Koval! Differential Revision: https://reviews.llvm.org/D41480 llvm-svn: 324255
* [InstCombine] Make foldSelectOpOp able to handle two-operand getelementptrJohn Brawn2018-01-191-7/+19
| | | | | | | | | | Three (or more) operand getelementptrs could plausibly also be handled, but handling only two-operand fits in easily with the existing BinaryOperator handling. Differential Revision: https://reviews.llvm.org/D39958 llvm-svn: 322930
* [InstCombine] fold min/max tree with common operand (PR35717)Sanjay Patel2018-01-081-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is precedence for factorization transforms in instcombine for FP ops with fast-math. We also have similar logic in foldSPFofSPF(). It would take more work to add this to reassociate because that's specialized for binops, and min/max are not binops (or even single instructions). Also, I don't have evidence that larger min/max trees than this exist in real code, but if we find that's true, we might want to reorganize where/how we do this optimization. In the motivating example from https://bugs.llvm.org/show_bug.cgi?id=35717 , we have: int test(int xc, int xm, int xy) { int xk; if (xc < xm) xk = xc < xy ? xc : xy; else xk = xm < xy ? xm : xy; return xk; } This patch solves that problem because we recognize more min/max patterns after rL321672 https://rise4fun.com/Alive/Qjne https://rise4fun.com/Alive/3yg Differential Revision: https://reviews.llvm.org/D41603 llvm-svn: 321998
* [InstCombine] relax use constraint for min/max (~a, ~b) --> ~min/max(a, b)Sanjay Patel2018-01-061-2/+2
| | | | | | | | | | | In the minimal case, this won't remove instructions, but it still improves uses of existing values. In the motivating example from PR35834, it does remove instructions, and sets that case up to be optimized by something like D41603: https://reviews.llvm.org/D41603 llvm-svn: 321936
* [InstCombine] add folds for min(~a, b) --> ~max(a, b)Sanjay Patel2018-01-051-22/+12
| | | | | | | | | | | | | | | | | Besides the bug of omitting the inverse transform of max(~a, ~b) --> ~min(a, b), the use checking and operand creation were off. We were potentially creating repeated identical instructions of existing values. This led to infinite looping after I added the extra folds. By using the simpler m_Not matcher and not creating new 'not' ops for a and b, we avoid that problem. It's possible that not using IsFreeToInvert() here is more limiting than the simpler matcher, but there are no tests for anything more exotic. It's also possible that we should relax the use checking further to handle a case like PR35834: https://bugs.llvm.org/show_bug.cgi?id=35834 ...but we can make that a follow-up if it is needed. llvm-svn: 321882
* [InstCombine] Simplify binops that are only used by a select and are fed by ↵Craig Topper2017-11-151-0/+40
| | | | | | | | | | | | | | | | | | | a select with the same condition. Summary: This patch optimizes a binop sandwiched between 2 selects with the same condition. Since we know its only used by the select we can propagate the appropriate input value from the earlier select. As I'm writing this I realize I may need to avoid doing this for division in case the select was protecting a divide by zero? Reviewers: spatel, majnemer Reviewed By: majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39999 llvm-svn: 318267
* [InstCombine] Simplify selects that test cmpxchg instructionsMatthew Simpson2017-10-311-0/+76
| | | | | | | | | | If a select instruction tests the returned flag of a cmpxchg instruction and selects between the returned value of the cmpxchg instruction and its compare operand, the result of the select will always be equal to its false value. Differential Revision: https://reviews.llvm.org/D39383 llvm-svn: 316994
* [Transforms] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-10-241-6/+26
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 316503
* [InstCombine] Move foldSelectICmpAnd helper function earlier in the file to ↵Craig Topper2017-09-051-105/+105
| | | | | | enable reuse in a future patch. llvm-svn: 312518
* [InstCombine] In foldSelectIntoOp, avoid creating a Constant before we know ↵Craig Topper2017-09-051-17/+18
| | | | | | | | | | for sure we're going to use it and avoid an unnecessary call to m_APInt. Instead of creating a Constant and then calling m_APInt with it (which will always return true). Just create an APInt initially, and use that for the checks in isSelect01 function. If it turns out we do need the Constant, create it from the APInt. This is a refactor for a future patch that will do some more checks of the constant values here. llvm-svn: 312517
* [InstCombine][InstSimplify] Teach decomposeBitTestICmp to look through ↵Craig Topper2017-09-011-1/+1
| | | | | | | | | | | | | | | | truncate instructions This patch teaches decomposeBitTestICmp to look through truncate instructions on the input to the compare. If a truncate is found it will now return the pre-truncated Value and appropriately extend the APInt mask. This allows some code to be removed from InstSimplify that was doing this functionality. This allows InstCombine's bit test combining code to match a pre-truncate Value with the same Value appear with an 'and' on another icmp. Or it allows us to combine a truncate to i16 and a truncate to i8. This also required removing the type check from the beginning of getMaskedTypeForICmpPair, but I believe that's ok because we still have to find two values from the input to each icmp that are equal before we'll do any transformation. So the type check was really just serving as an early out. There was one user of decomposeBitTestICmp that didn't want to look through truncates, so I've added a flag to prevent that behavior when necessary. Differential Revision: https://reviews.llvm.org/D37158 llvm-svn: 312382
* [InstCombine] remove unnecessary vector select fold; NFCISanjay Patel2017-08-301-4/+0
| | | | | | | | | | This code is double-dead: 1. We simplify all selects with constant true/false condition in InstSimplify. I've minimized/moved the tests to show that works as expected. 2. All remaining vector selects with a constant condition are canonicalized to shufflevector, so we really can't see this pattern. llvm-svn: 312123
* [InstCombine] Teach foldSelectICmpAndOr to handle vector splatsCraig Topper2017-08-291-6/+8
| | | | | | | | This was pretty close to working already. While I was here I went ahead and passed the ICmpInst pointer from the caller instead of doing a dyn_cast that can never fail. Differential Revision: https://reviews.llvm.org/D37237 llvm-svn: 311960
* [InstCombine] Teach select01 helper of foldSelectIntoOp to handle vector splatsCraig Topper2017-08-281-7/+6
| | | | | | | | We were handling some vectors in foldSelectIntoOp, but not if the operand of the bin op was any kind of vector constant. This patch fixes it to treat vector splats the same as scalars. Differential Revision: https://reviews.llvm.org/D37232 llvm-svn: 311940
* [InstCombine] Teach foldSelectICmpAnd to recognize a (icmp slt X, 0) and ↵Craig Topper2017-08-211-19/+49
| | | | | | | | | | (icmp sgt X, -1) as equivalent to an and with the sign bit of the truncated type This is similar to what was already done in foldSelectICmpAndOr. Ultimately I'd like to see if we can call foldSelectICmpAnd from foldSelectIntoOp if we detect a power of 2 constant. This would allow us to remove foldSelectICmpAndOr entirely. Differential Revision: https://reviews.llvm.org/D36498 llvm-svn: 311362
* [InstCombine] Make folding (X >s -1) ? C1 : C2 --> ((X >>s 31) & (C2 - C1)) ↵Craig Topper2017-08-161-17/+22
| | | | | | | | | | + C1 support splat vectors This also uses decomposeBitTestICmp to decode the compare. Differential Revision: https://reviews.llvm.org/D36781 llvm-svn: 311044
* [InstCombine] Cast to BinaryOperator earlier in foldSelectIntoOp to simplify ↵Craig Topper2017-08-081-14/+10
| | | | | | | | the code. We no longer need the explicit operand count check or the later dynamic cast. llvm-svn: 310339
* [InstCombine] Support vector splats in foldSelectICmpAnd.Craig Topper2017-08-051-15/+23
| | | | | | Unfortunately, it looks like there's some other missed optimizations in the generated code for some of these cases. I'll try to look at some of those next. llvm-svn: 310184
* [InstCombine] In foldSelectICmpAnd, if we need to to truncate from the 'and' ↵Craig Topper2017-08-051-8/+8
| | | | | | | | | | | | type to the 'select' type, do it after shifting right instead of just bailing. Previously we were always trying to emit the zext or truncate before any shift. This meant if the 'and' mask was larger than the size of the truncate we would skip the transformation. Now we shift the result of the and right first leaving the bit within the range of the truncate. This matches what we are doing in foldSelectICmpAndOr for the same problem. llvm-svn: 310159
* [InstCombine] Use ConstantInt::getFalse to reduce some code. NFCCraig Topper2017-08-041-2/+1
| | | | llvm-svn: 310062
* [InstCombine] Canonicalize clamp of float types to minmax in fast mode.Nikolai Bozhenov2017-08-041-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows matchSelectPattern to recognize clamp of float arguments in the presence of FMF the same way as already done for integers. This case is a little different though. With integers, given the min/max pattern is recognized, DAGBuilder starts selecting MIN/MAX "automatically". That is not the case for float, because for them only full FMINNAN/FMINNUM/FMAXNAN/FMAXNUM ISD nodes exist and they do care about NaNs. On the other hand, some backends (e.g. X86) have only FMIN/FMAX nodes that do not care about NaNS and the former NAN/NUM nodes are illegal thus selection is not happening. So I decided to do such kind of transformation in IR (InstCombiner) instead of complicating the logic in the backend. Reviewers: spatel, jmolloy, majnemer, efriedma, craig.topper Reviewed By: efriedma Subscribers: hiraditya, javed.absar, n.bozhenov, llvm-commits Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D33186 llvm-svn: 310054
* [InstCombine] Move the call to foldSelectICmpAnd into ↵Craig Topper2017-08-041-80/+80
| | | | | | foldSelectInstWithICmp. NFCI llvm-svn: 310025
* [Value Tracking] Default argument to true and rename accordingly. NFC.Chad Rosier2017-08-011-2/+2
| | | | | | IMHO this is a bit more readable. llvm-svn: 309739
* Disable loop unswitching for some patterns containing equality comparison ↵Wei Mi2017-07-251-0/+16
| | | | | | | | | | | | | | | | | | | with undef. This is a workaround for the bug described in PR31652 and http://lists.llvm.org/pipermail/llvm-dev/2017-July/115497.html. The temporary solution is to add a function EqualityPropUnSafe. In EqualityPropUnSafe, for some simple patterns we can know the equality comparison may contains undef, so we regard such comparison as unsafe and will not do loop-unswitching for them. We also need to disable the select simplification when one of select operand is undef and its result feeds into equality comparison. The patch cannot clear the safety issue caused by the bug, but it can suppress the issue from happening to some extent. Differential Revision: https://reviews.llvm.org/D35811 llvm-svn: 309059
* [IR] Add Type::isIntOrIntVectorTy(unsigned) similar to the existing ↵Craig Topper2017-07-091-2/+2
| | | | | | isIntegerTy(unsigned), but also works for vectors. llvm-svn: 307492
* [InstCombine] Speculatively implement a fix for what might be the root cause ↵Craig Topper2017-07-091-1/+2
| | | | | | | | | | of PR33721 by making sure that we have integer types before doing select C, -1, 0 -> sext C to int I recently changed m_One and m_AllOnes to use Constant::isOneValue/isAllOnesValue which work on floating point values too. The original implementation looked specifically for ConstantInt scalars and splats. So I'm guessing we are accidentally trying to issue sext/zexts on floating point types now. Hopefully I figure out how to reproduce the failure from the PR soon. llvm-svn: 307486
* [InstCombine] Make InstCombine's IRBuilder be passed by reference everywhereCraig Topper2017-07-071-70/+69
| | | | | | | | 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-5/+5
| | | | | | | | 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] Don't create extra ConstantInt objects in foldSelectICmpAnd. NFCICraig Topper2017-07-061-19/+17
| | | | | | Instead just use APInt objects and only create a ConstantInt at the end if we need it for the Offset. llvm-svn: 307270
* Revert of r306525: "Canonicalize clamp of float types to minmax"Nikolai Bozhenov2017-06-301-10/+3
| | | | llvm-svn: 306815
* [InstCombine] Canonicalize clamp of float types to minmax in fast mode.Nikolai Bozhenov2017-06-281-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows matchSelectPattern to recognize clamp of float arguments in the presence of FMF the same way as already done for integers. This case is a little different though. With integers, given the min/max pattern is recognized, DAGBuilder starts selecting MIN/MAX "automatically". That is not the case for float, because for them only full FMINNAN/FMINNUM/FMAXNAN/FMAXNUM ISD nodes exist and they do care about NaNs. On the other hand, some backends (e.g. X86) have only FMIN/FMAX nodes that do not care about NaNS and the former NAN/NUM nodes are illegal thus selection is not happening. So I decided to do such kind of transformation in IR (InstCombiner) instead of complicating the logic in the backend. Reviewers: spatel, jmolloy, majnemer, efriedma, craig.topper Reviewed By: efriedma Subscribers: hiraditya, javed.absar, n.bozhenov, llvm-commits Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D33186 llvm-svn: 306525
* [InstCombine] canonicalize icmp predicate feeding selectSanjay Patel2017-06-271-0/+17
| | | | | | | | | | | | | | | | | | | | | This canonicalization was suggested in D33172 as a way to make InstCombine behavior more uniform. We have this transform for icmp+br, so unless there's some reason that icmp+select should be treated differently, we should do the same thing here. The benefit comes from increasing the chances of creating identical instructions. This is shown in the tests in logical-select.ll (PR32791). InstCombine doesn't fold those directly, but EarlyCSE can simplify the identical cmps, and then InstCombine can fold the selects together. The possible regression for the tests in select.ll raises questions about poison/undef: http://lists.llvm.org/pipermail/llvm-dev/2017-May/113261.html ...but that transform is just as likely to be triggered by this canonicalization as it is to be missed, so we're just pointing out a commutation deficiency in the pattern matching: https://reviews.llvm.org/rL228409 Differential Revision: https://reviews.llvm.org/D34242 llvm-svn: 306435
* [InstCombine] Teach foldSelectICmpAndOr to recognize (select (icmp slt ↵Craig Topper2017-06-221-11/+38
| | | | | | | | | | | | | | | | | | | (trunc (X)), 0), Y, (or Y, C2)) Summary: InstCombine likes to turn (icmp eq (and X, C1), 0) into (icmp slt (trunc (X)), 0) sometimes. This breaks foldSelectICmpAndOr's ability to recognize (select (icmp eq (and X, C1), 0), Y, (or Y, C2))->(or (shl (and X, C1), C3), y). This patch tries to recover this. I had to flip around some of the early out checks so that I could create a new And instruction during the compare processing without it possibly never getting used. Reviewers: spatel, majnemer, davide Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34184 llvm-svn: 306029
OpenPOWER on IntegriCloud