summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Fix a vector splat handling bug in transformZExtICmp.Craig Topper2017-10-051-3/+1
| | | | | | | | | | We were using an i1 type and then zero extending to a vector. Instead just create the 0/1 directly as a ConstantInt with the correct type. No need to ask ConstantExpr to zero extend for us. This bug is a bit tricky to hit because it requires us to visit a zext of an icmp that would normally be simplified to true/false, but that icmp hasnt' been visited yet. In the test case this zext and icmp were created by visiting a udiv and due to worklist ordering we got to the zext first. Fixes PR34841. llvm-svn: 314971
* [InstCombine] Support vector splats in transformZExtICmpCraig Topper2017-08-291-7/+7
| | | | | | | | | | This patch adds splat support to transformZExtICmp. The test cases are vector versions of tests that failed when commenting out parts of the existing scalar code. One test didn't vectorize optimize properly due to another bug so a TODO has been added. Differential Revision: https://reviews.llvm.org/D37253 llvm-svn: 312023
* [InstCombine] Fix a weakness in canEvaluateZExtd around 'and' instructionsCraig Topper2017-08-211-1/+6
| | | | | | | | | | | | | | | | | Summary: If the bitsToClear from the LHS of an 'and' comes back non-zero, but all of those bits are known zero on the RHS, we can reset bitsToClear. Without this, the 'or' in the modified test case blocks the transform because it has non-zero bits in its RHS in those bits. Reviewers: spatel, majnemer, davide Reviewed By: davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36944 llvm-svn: 311343
* [InstCombine] Teach canEvaluateTruncated to handle arithmetic shift ↵Amjad Aboud2017-08-161-0/+17
| | | | | | | | (including those with vector splat shift amount) Differential Revision: https://reviews.llvm.org/D36784 llvm-svn: 311050
* [InstCombine] Teach canEvaluateZExtd and canEvaluateTruncated to handle ↵Craig Topper2017-08-151-10/+18
| | | | | | | | | | vector shifts with splat shift amount We were only allowing ConstantInt before. This patch allows splat of ConstantInt too. Differential Revision: https://reviews.llvm.org/D36763 llvm-svn: 310970
* [InstCombine] narrow rotate left/right patterns to eliminate zext/trunc ↵Sanjay Patel2017-08-091-1/+72
| | | | | | | | | | | | | | | | | | | | | | | (PR34046) I couldn't find any smaller folds to help the cases in: https://bugs.llvm.org/show_bug.cgi?id=34046 after: rL310141 The truncated rotate-by-variable patterns elude all of the existing transforms because of multiple uses and knowledge about demanded bits and knownbits that doesn't exist without the whole pattern. So we need an unfortunately large pattern match. But by simplifying this pattern in IR, the backend is already able to generate rolb/rolw/rorb/rorw for x86 using its existing rotate matching logic (although there is a likely extraneous 'and' of the rotate amount). Note that rotate-by-constant doesn't have this problem - smaller folds should already produce the narrow IR ops. Differential Revision: https://reviews.llvm.org/D36395 llvm-svn: 310509
* [InstCombine] refactor trunc(binop) transforms; NFCISanjay Patel2017-08-051-39/+37
| | | | | | | In addition to moving the shift transforms over, we may want to detect too-wide rotate patterns here (PR34046). llvm-svn: 310181
* [InstCombine] narrow truncated add/sub/mul with constantSanjay Patel2017-08-041-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Name: narrow_sub %sub = sub i32 C1, %x %r = trunc i32 %sub to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = sub i8 %narrowC, %xn Name: narrow_add %add = add i32 %x, C1 %r = trunc i32 %add to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = add i8 %xn, %narrowC Name: narrow_mul %mul = mul i32 %x, C1 %r = trunc i32 %mul to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = mul i8 %xn, %narrowC http://rise4fun.com/Alive/QpS This doesn't solve PR34046 (failure to recognize rotate): https://bugs.llvm.org/show_bug.cgi?id=34046 ...but it reduces an extra complication in the description examples to a form that we can more easily match. llvm-svn: 310141
* [InstCombine] Remove unnecessary casts. NFCCraig Topper2017-08-041-2/+2
| | | | | | We're calling an overload of getOpcode that already returns Instruction::CastOps. llvm-svn: 310024
* [IR] Make use of ↵Craig Topper2017-07-091-1/+1
| | | | | | Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC llvm-svn: 307491
* [InstCombine] Make InstCombine's IRBuilder be passed by reference everywhereCraig Topper2017-07-071-80/+78
| | | | | | | | 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
* [InstCombine] No need to pass DataLayout to helper functions if we're ↵Craig Topper2017-07-061-7/+5
| | | | | | passing the InstCombiner object. We can just ask it for the DataLayout. NFC llvm-svn: 307333
* [InstCombine] reverse bitcast + bitwise-logic canonicalization (PR33138)Sanjay Patel2017-06-221-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [InstCombine][InstSimplify] Use APInt::isNullValue/isOneValue to reduce ↵Craig Topper2017-06-071-4/+4
| | | | | | | | compiled code for comparing APInts with 0 and 1. NFC These methods are specifically optimized to only counting leading zeros without an additional uint64_t compare. llvm-svn: 304876
* [ValueTracking] Convert most of the calls to computeKnownBits to use the ↵Craig Topper2017-05-241-11/+5
| | | | | | | | | | version that returns the KnownBits object. This continues the changes started when computeSignBit was replaced with this new version of computeKnowBits. Differential Revision: https://reviews.llvm.org/D33431 llvm-svn: 303773
* [InstCombine] Take in account the size in sext->lshr->trunc patterns.Davide Italiano2017-05-211-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we end up miscompiling, transforming: define i8 @tinky() { %sext = sext i1 1 to i16 %hibit = lshr i16 %sext, 15 %tr = trunc i16 %hibit to i8 ret i8 %tr } into: %sext = sext i1 1 to i8 ret i8 %sext and the first get folded to ret i8 1, while the second gets folded to ret i8 -1. Eventually we should get rid of this transform entirely, but for now, this at least fixes a know correctness bug. Differential Revision: https://reviews.llvm.org/D33338 llvm-svn: 303513
* [ValueTracking] Replace all uses of ComputeSignBit with computeKnownBits.Craig Topper2017-05-151-3/+2
| | | | | | | | This patch finishes off the conversion of ComputeSignBit to computeKnownBits. Differential Revision: https://reviews.llvm.org/D33166 llvm-svn: 303035
* [InstCombineCasts] Fix checks in sext->lshr->trunc pattern.Sanjay Patel2017-05-091-6/+14
| | | | | | | | | | | | | | | The comment says to avoid the case where zero bits are shifted into the truncated value, but the code checks that the shift is smaller than the truncated value instead of the number of bits added by the sign extension. Fixing this allows a shift by more than the value size to be introduced, which is undefined behavior, so the shift is capped at the value size minus one, which has the expected behavior of filling the value with the sign bit. Patch by Jacob Young! Differential Revision: https://reviews.llvm.org/D32285 llvm-svn: 302548
* [ValueTracking] Introduce a KnownBits struct to wrap the two APInts for ↵Craig Topper2017-04-261-15/+15
| | | | | | | | | | | | | | | | computeKnownBits This patch introduces a new KnownBits struct that wraps the two APInt used by computeKnownBits. This allows us to treat them as more of a unit. Initially I've just altered the signatures of computeKnownBits and InstCombine's simplifyDemandedBits to pass a KnownBits reference instead of two separate APInt references. I'll do similar to the SelectionDAG version of computeKnownBits/simplifyDemandedBits as a separate patch. I've added a constructor that allows initializing both APInts to the same bit width with a starting value of 0. This reduces the repeated pattern of initializing both APInts. Once place default constructed the APInts so I added a default constructor for those cases. Going forward I would like to add more methods that will work on the pairs. For example trunc, zext, and sext occur on both APInts together in several places. We should probably add a clear method that can be used to clear both pieces. Maybe a method to check for conflicting information. A method to return (Zero|One) so we don't write it out everywhere. Maybe a method for (Zero|One).isAllOnesValue() to determine if all bits are known. I'm sure there are many other methods we can come up with. Differential Revision: https://reviews.llvm.org/D32376 llvm-svn: 301432
* Add a getPointerOperandType() helper to LoadInst and StoreInst; NFCSanjoy Das2017-04-181-1/+1
| | | | | | I will use this in a later change. llvm-svn: 300613
* [InstCombine] Support folding a subtract with a constant LHS into a phi nodeCraig Topper2017-04-141-2/+2
| | | | | | | | | | | | We currently only support folding a subtract into a select but not a PHI. This fixes that. I had to fix an assumption in FoldOpIntoPhi that assumed the PHI node was always in operand 0. Now we pass it in like we do for FoldOpIntoSelect. But we still require some dancing to find the Constant when we create the BinOp or ConstantExpr. This is based code is similar to what we do for selects. Since I touched all call sites, this also renames FoldOpIntoPhi to foldOpIntoPhi to match coding standards. Differential Revision: https://reviews.llvm.org/D31686 llvm-svn: 300363
* InstCombine: Check source value precision when reducing cast intrinsicMatt Arsenault2017-03-201-2/+14
| | | | | | Missed this check when porting from the libcall version. llvm-svn: 298312
* [InstCombine] Liberate assert in InstCombiner::visitZExtBjorn Pettersson2017-03-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The call to canEvaluateZExtd in InstCombiner::visitZExt may return with BitsToClear == SrcTy->getScalarSizeInBits(), but there is an assert that BitsToClear should be smaller than SrcTy->getScalarSizeInBits(). I have a test case that triggers the assert, but it only happens for my downstream target. I've not been able to trigger it for any upstream target. The assert triggered for a piece of code such as this %shr1 = lshr i16 undef, 15 ... %shr2 = lshr i16 %shr1, 1 %conv = zext i16 %shr2 to i32 Normally the lshr instructions are constant folded before we visit the zext (that is why it is so hard to reproduce). The original pattern, before instcombine, is of course a lot more complicated in my test case. The shift count in the second lshr is for example determined by the outcome of a PHI instruction. It seems like other rewrites by instcombine leads up to the pattern above. And then the zext is pulled from the worklist, and visited (hitting the assert), before we detect that the lshr instrucions can be constant folded. Anyway, since the canEvaluateZExtd may return with BitsToClear equal to SrcTy->getScalarSizeInBits(), and since the rewrite that converts the expression type to avoid a zero extend works also for the case where SrcBitsKept ends up being zero, then it should be OK to liberate the assert to assert(BitsToClear <= SrcTy->getScalarSizeInBits() && "Unreasonable BitsToClear"); Reviewers: hfinkel Reviewed By: hfinkel Subscribers: hfinkel, llvm-commits Differential Revision: https://reviews.llvm.org/D30993 llvm-svn: 297952
* [InstCombine] avoid crashing on shuffle shrinkage when input type is not ↵Sanjay Patel2017-03-081-1/+2
| | | | | | same as result type llvm-svn: 297280
* [InstCombine] shrink truncated insertelement into undef vectorSanjay Patel2017-03-071-0/+38
| | | | | | | | | | | | This is the 2nd part of solving: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110293.html D30123 moves the trunc ahead of the shuffle, and this moves the trunc ahead of the insertelement. We're limiting this transform to undef rather than any constant to avoid backend problems. Differential Revision: https://reviews.llvm.org/D30137 llvm-svn: 297242
* [InstCombine] shrink truncated splat shuffle (2nd try)Sanjay Patel2017-03-071-0/+20
| | | | | | | | | | | | | | | | This was committed at r297155 and reverted at r297166 because of an over-reaching clang test. That should be fixed with r297189. This is one part of solving a recent bug report: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110293.html This keeps with our general approach: changing arbitrary shuffles is off-limts, but changing splat is ok. The transform is very similar to the existing shrinkBitwiseLogic() canonicalization. Differential Revision: https://reviews.llvm.org/D30123 llvm-svn: 297232
* revert r297155 because there's a clang test that depends on InstCombine:Sanjay Patel2017-03-071-20/+0
| | | | | | tools/clang/test/CodeGen/zvector.c llvm-svn: 297166
* [InstCombine] shrink truncated splat shuffleSanjay Patel2017-03-071-0/+20
| | | | | | | | | | | | | This is one part of solving a recent bug report: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110293.html This keeps with our general approach: changing arbitrary shuffles is off-limts, but changing splat is ok. The transform is very similar to the existing shrinkBitwiseLogic() canonicalization. Differential Revision: https://reviews.llvm.org/D30123 llvm-svn: 297155
* [InstCombine] don't try SimplifyDemandedInstructionBits from zext/sext ↵Sanjay Patel2017-02-241-10/+0
| | | | | | | | | | | | | | | | | | | | because it's slow and unnecessary This one seems more obvious than D30270 that it can't make improvements because an extension always needs all of the incoming bits. There's one specific transform in SimplifyDemandedInstructionBits of converting a sext to a zext when the sign-bit is known zero, but that is handled explicitly in visitSext() with ComputeSignBit(). Like D30270, there are no IR differences (other than instruction names) for the case in PR32037: https://bugs.llvm.org//show_bug.cgi?id=32037 ...and no regression test differences. Zext/sext are a smaller part of the profile, but this still appears to shave off another 0.5% or so from 'opt -O2'. Differential Revision: https://reviews.llvm.org/D30280 llvm-svn: 296129
* [InstCombine] use loop instead of recursion to peek through FPExt; NFCISanjay Patel2017-02-231-6/+4
| | | | llvm-svn: 295992
* [InstCombine] use 'match' to reduce code; NFCISanjay Patel2017-02-231-11/+9
| | | | llvm-svn: 295991
* fix formatting; NFCSanjay Patel2017-01-311-6/+6
| | | | llvm-svn: 293652
* SimplifyLibCalls: Replace more unary libcalls with intrinsicsMatt Arsenault2017-01-231-1/+8
| | | | llvm-svn: 292855
* SimplifyLibCalls: Replace fabs libcalls with intrinsicsMatt Arsenault2017-01-171-15/+18
| | | | | | | | Add missing fabs(fpext) optimzation that worked with the call, and also fixes it creating a second fpext when there were multiple uses. llvm-svn: 292172
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-3/+3
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* [InstCombine] change select type to eliminate bitcastsSanjay Patel2016-12-031-0/+47
| | | | | | | | | | | | | | This solves a secondary problem seen in PR6137: https://llvm.org/bugs/show_bug.cgi?id=6137#c6 This is similar to the bitwise logic op fold added with: https://reviews.llvm.org/rL287707 And like that patch, I'm artificially restricting the transform from vector <-> scalar types until we're sure that the backend can handle that. llvm-svn: 288584
* [InstCombine] allow more narrowing transforms for logic opsSanjay Patel2016-11-301-9/+23
| | | | | | | We had a limited version of this for scalar 'and'; this expands the transform to 'or' and 'xor' and allows vectors types too. llvm-svn: 288273
* add and use isBitwiseLogicOp() helper function; NFCISanjay Patel2016-11-221-15/+7
| | | | llvm-svn: 287712
* [InstCombine] change bitwise logic type to eliminate bitcastsSanjay Patel2016-11-221-0/+43
| | | | | | | | | | | | | | | | | | | | In PR27925: https://llvm.org/bugs/show_bug.cgi?id=27925 ...we proposed adding this fold to eliminate a bitcast. In D20774, there was some concern about changing the type of a bitwise op as well as creating bitcasts that might not be free for a target. However, if we're strictly eliminating an instruction (by limiting this to one-use ops), then we should be able to do this in InstCombine. But we're cautiously restricting the transform for now to vector types to avoid possible backend problems. A transform to make sure the logic op is legal for the target should be added to reverse this transform and improve codegen. Differential Revision: https://reviews.llvm.org/D26641 llvm-svn: 287707
* [InstCombine] clean up commonCastTransforms; NFCSanjay Patel2016-10-261-11/+9
| | | | | | | | 1. Use 'auto' with dyn_cast. 2. Variables start with a capital letter. 3. Use proper punctuation in comments. llvm-svn: 285200
* [InstCombine] Resubmit the combine of A->B->A BitCast and fix for pr27996Guozhi Wei2016-10-251-0/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original patch of the A->B->A BitCast optimization was reverted by r274094 because it may cause infinite loop inside compiler https://llvm.org/bugs/show_bug.cgi?id=27996. The problem is with following code xB = load (type B); xA = load (type A); +yA = (A)xB; B -> A +zAn = PHI[yA, xA]; PHI +zBn = (B)zAn; // A -> B store zAn; store zBn; optimizeBitCastFromPhi generates +zBn = (B)zAn; // A -> B and expects it will be combined with the following store instruction to another store zAn Unfortunately before combineStoreToValueType is called on the store instruction, optimizeBitCastFromPhi is called on the new BitCast again, and this pattern repeats indefinitely. optimizeBitCastFromPhi only generates BitCast for load/store instructions, only the BitCast before store can cause the reexecution of optimizeBitCastFromPhi, and BitCast before store can easily be handled by InstCombineLoadStoreAlloca.cpp. So the solution to the problem is if all users of a CI are store instructions, we should not do optimizeBitCastFromPhi on it. Then optimizeBitCastFromPhi will not be called on the new BitCast instructions. Differential Revision: https://reviews.llvm.org/D23896 llvm-svn: 285116
* Reapply "InstCombine: Reduce trunc (shl x, K) width."Matt Arsenault2016-09-131-7/+25
| | | | | | | This reapplies r272987 with a fix for infinitely looping when the truncated value is another shift of a constant. llvm-svn: 281379
* InstCombine: Clean up some trailing whitespace. NFCJustin Bogner2016-08-051-3/+3
| | | | llvm-svn: 277793
* InstCombine: Replace some never-null pointers with references. NFCJustin Bogner2016-08-051-1/+1
| | | | llvm-svn: 277792
* [InstCombine] Refactor optimization of zext(or(icmp, icmp)) to enable more ↵Tobias Grosser2016-08-031-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ConstnatFolding] Teach the folder how to fold ConstantVectorDavid Majnemer2016-07-291-3/+2
| | | | | | | | | | | 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
* [InstCombine] Handle failures from ConstantFoldConstantExpressionDavid Majnemer2016-07-281-1/+2
| | | | | | | | ConstantFoldConstantExpression returns null when folding fails. This fixes PR28745. llvm-svn: 276952
* [InstCombine] LogicOpc (zext X), C --> zext (LogicOpc X, C) (PR28476)Sanjay Patel2016-07-211-8/+0
| | | | | | | | | | | | | | | | 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
* [InstCombine] Minor cleanup of cast simplification code [NFC]Tobias Grosser2016-07-191-46/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "InstCombine rule to fold truncs whose value is available"Anna Thomas2016-07-081-23/+1
| | | | | | | This reverts commit r274853. Caused failure in ppcBE build llvm-svn: 274943
OpenPOWER on IntegriCloud