summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [ObjCARC] Do not move a release between a call and aAkira Hatanaka2017-04-291-0/+25
| | | | | | | | | | | | | | | | | | | retainAutoreleasedReturnValue that retains the returned value. This commit fixes a bug in ARC optimizer where it moves a release between a call and a retainAutoreleasedReturnValue, causing the returned object to be released before the retainAutoreleasedReturnValue can retain it. This commit accomplishes that by doing a lookahead and checking whether the call prevents the release from moving upwards. In the long term, we should treat the region between the retainAutoreleasedReturnValue and the call as a critical section and disallow moving anything there (possibly using operand bundles). rdar://problem/20449878 llvm-svn: 301724
* [LoopUnswitch] Don't remove instructions with side effects.Davide Italiano2017-04-291-0/+19
| | | | | | | | This fixes PR32818. Differential Revision: https://reviews.llvm.org/D32664 llvm-svn: 301722
* [InstCombine] add tests to show potentially bogus application of DeMorgan (NFC)Sanjay Patel2017-04-281-0/+22
| | | | llvm-svn: 301714
* InferAddressSpaces: Search constant expressions for addrspacecastsMatt Arsenault2017-04-282-3/+20
| | | | | | | These are pretty common when using local memory, and the 64-bit generic addressing is much more expensive to compute. llvm-svn: 301711
* InferAddressSpaces: Infer from just addrspacecastsMatt Arsenault2017-04-282-7/+58
| | | | | | | | Eliminates some more cases where some subset of the addressing computation remains flat. Some cases with addrspacecasts in nested constant expressions are still left behind however. llvm-svn: 301704
* [ValueTracking] Teach isSafeToSpeculativelyExecute() about the speculatable ↵Matt Arsenault2017-04-281-0/+23
| | | | | | | | attribute Patch by Tom Stellard llvm-svn: 301688
* [InlineCost] Improve the cost heuristic for SwitchJun Bum Lim2017-04-281-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The motivation example is like below which has 13 cases but only 2 distinct targets ``` lor.lhs.false2: ; preds = %if.then switch i32 %Status, label %if.then27 [ i32 -7012, label %if.end35 i32 -10008, label %if.end35 i32 -10016, label %if.end35 i32 15000, label %if.end35 i32 14013, label %if.end35 i32 10114, label %if.end35 i32 10107, label %if.end35 i32 10105, label %if.end35 i32 10013, label %if.end35 i32 10011, label %if.end35 i32 7008, label %if.end35 i32 7007, label %if.end35 i32 5002, label %if.end35 ] ``` which is compiled into a balanced binary tree like this on AArch64 (similar on X86) ``` .LBB853_9: // %lor.lhs.false2 mov w8, #10012 cmp w19, w8 b.gt .LBB853_14 // BB#10: // %lor.lhs.false2 mov w8, #5001 cmp w19, w8 b.gt .LBB853_18 // BB#11: // %lor.lhs.false2 mov w8, #-10016 cmp w19, w8 b.eq .LBB853_23 // BB#12: // %lor.lhs.false2 mov w8, #-10008 cmp w19, w8 b.eq .LBB853_23 // BB#13: // %lor.lhs.false2 mov w8, #-7012 cmp w19, w8 b.eq .LBB853_23 b .LBB853_3 .LBB853_14: // %lor.lhs.false2 mov w8, #14012 cmp w19, w8 b.gt .LBB853_21 // BB#15: // %lor.lhs.false2 mov w8, #-10105 add w8, w19, w8 cmp w8, #9 // =9 b.hi .LBB853_17 // BB#16: // %lor.lhs.false2 orr w9, wzr, #0x1 lsl w8, w9, w8 mov w9, #517 and w8, w8, w9 cbnz w8, .LBB853_23 .LBB853_17: // %lor.lhs.false2 mov w8, #10013 cmp w19, w8 b.eq .LBB853_23 b .LBB853_3 .LBB853_18: // %lor.lhs.false2 mov w8, #-7007 add w8, w19, w8 cmp w8, #2 // =2 b.lo .LBB853_23 // BB#19: // %lor.lhs.false2 mov w8, #5002 cmp w19, w8 b.eq .LBB853_23 // BB#20: // %lor.lhs.false2 mov w8, #10011 cmp w19, w8 b.eq .LBB853_23 b .LBB853_3 .LBB853_21: // %lor.lhs.false2 mov w8, #14013 cmp w19, w8 b.eq .LBB853_23 // BB#22: // %lor.lhs.false2 mov w8, #15000 cmp w19, w8 b.ne .LBB853_3 ``` However, the inline cost model estimates the cost to be linear with the number of distinct targets and the cost of the above switch is just 2 InstrCosts. The function containing this switch is then inlined about 900 times. This change use the general way of switch lowering for the inline heuristic. It etimate the number of case clusters with the suitability check for a jump table or bit test. Considering the binary search tree built for the clusters, this change modifies the model to be linear with the size of the balanced binary tree. The model is off by default for now : -inline-generic-switch-cost=false This change was originally proposed by Haicheng in D29870. Reviewers: hans, bmakam, chandlerc, eraman, haicheng, mcrosier Reviewed By: hans Subscribers: joerg, aemerson, llvm-commits, rengolin Differential Revision: https://reviews.llvm.org/D31085 llvm-svn: 301649
* Memory intrinsic value profile optimization: Avoid divide by 0Teresa Johnson2017-04-281-0/+19
| | | | | | | | | | | | | | Summary: Skip memops if the total value profiled count is 0, we can't correctly scale up the counts and there is no point anyway. Reviewers: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32624 llvm-svn: 301645
* [EarlyCSE] Mark the condition of assume intrinsic as trueMax Kazantsev2017-04-281-0/+190
| | | | | | | | | | | | | | EarlyCSE should not just ignore assumes. It should use the fact that its condition is true for all dominated instructions. Reviewers: sanjoy, reames, apilipenko, anna, skatkov Reviewed By: reames, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32482 llvm-svn: 301625
* [EarlyCSE] Remove guards with conditions known to be trueMax Kazantsev2017-04-281-0/+156
| | | | | | | | | | | | | | | | | If a condition is calculated only once, and there are multiple guards on this condition, we should be able to remove all guards dominated by the first of them. This patch allows EarlyCSE to try to find the condition of a guard among the known values, and if it is true, remove the guard. Otherwise we keep the guard and mark its condition as 'true' for future consideration. Reviewers: sanjoy, reames, apilipenko, skatkov, anna, dberlin Reviewed By: reames, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32476 llvm-svn: 301623
* [InstCombine] fix matcher to bind to specific operand (PR32830)Sanjay Patel2017-04-271-0/+20
| | | | | | | Matching any random value would be very wrong: https://bugs.llvm.org/show_bug.cgi?id=32830 llvm-svn: 301594
* [PM/LoopUnswitch] Introduce a new, simpler loop unswitch pass.Chandler Carruth2017-04-2729-0/+1719
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, this pass only focuses on *trivial* loop unswitching. At that reduced problem it remains significantly better than the current loop unswitch: - Old pass is worse than cubic complexity. New pass is (I think) linear. - New pass is much simpler in its design by focusing on full unswitching. (See below for details on this). - New pass doesn't carry state for thresholds between pass iterations. - New pass doesn't carry state for correctness (both miscompile and infloop) between pass iterations. - New pass produces substantially better code after unswitching. - New pass can handle more trivial unswitch cases. - New pass doesn't recompute the dominator tree for the entire function and instead incrementally updates it. I've ported all of the trivial unswitching test cases from the old pass to the new one to make sure that major functionality isn't lost in the process. For several of the test cases I've worked to improve the precision and rigor of the CHECKs, but for many I've just updated them to handle the new IR produced. My initial motivation was the fact that the old pass carried state in very unreliable ways between pass iterations, and these mechansims were incompatible with the new pass manager. However, I discovered many more improvements to make along the way. This pass makes two very significant assumptions that enable most of these improvements: 1) Focus on *full* unswitching -- that is, completely removing whatever control flow construct is being unswitched from the loop. In the case of trivial unswitching, this means removing the trivial (exiting) edge. In non-trivial unswitching, this means removing the branch or switch itself. This is in opposition to *partial* unswitching where some part of the unswitched control flow remains in the loop. Partial unswitching only really applies to switches and to folded branches. These are very similar to full unrolling and partial unrolling. The full form is an effective canonicalization, the partial form needs a complex cost model, cannot be iterated, isn't canonicalizing, and should be a separate pass that runs very late (much like unrolling). 2) Leverage LLVM's Loop machinery to the fullest. The original unswitch dates from a time when a great deal of LLVM's loop infrastructure was missing, ineffective, and/or unreliable. As a consequence, a lot of complexity was added which we no longer need. With these two overarching principles, I think we can build a fast and effective unswitcher that fits in well in the new PM and in the canonicalization pipeline. Some of the remaining functionality around partial unswitching may not be relevant today (not many test cases or benchmarks I can find) but if they are I'd like to add support for them as a separate layer that runs very late in the pipeline. Purely to make reviewing and introducing this code more manageable, I've split this into first a trivial-unswitch-only pass and in the next patch I'll add support for full non-trivial unswitching against a *fixed* threshold, exactly like full unrolling. I even plan to re-use the unrolling thresholds, as these are incredibly similar cost tradeoffs: we're cloning a loop body in order to end up with simplified control flow. We should only do that when the total growth is reasonably small. One of the biggest changes with this pass compared to the previous one is that previously, each individual trivial exiting edge from a switch was unswitched separately as a branch. Now, we unswitch the entire switch at once, with cases going to the various destinations. This lets us unswitch multiple exiting edges in a single operation and also avoids numerous extremely bad behaviors, where we would introduce 1000s of branches to test for thousands of possible values, all of which would take the exact same exit path bypassing the loop. Now we will use a switch with 1000s of cases that can be efficiently lowered into a jumptable. This avoids relying on somehow forming a switch out of the branches or getting horrible code if that fails for any reason. Another significant change is that this pass actively updates the CFG based on unswitching. For trivial unswitching, this is actually very easy because of the definition of loop simplified form. Doing this makes the code coming out of loop unswitch dramatically more friendly. We still should run loop-simplifycfg (at the least) after this to clean up, but it will have to do a lot less work. Finally, this pass makes much fewer attempts to simplify instructions based on the unswitch. Something like loop-instsimplify, instcombine, or GVN can be used to do increasingly powerful simplifications based on the now dominating predicate. The old simplifications are things that something like loop-instsimplify should get today or a very, very basic loop-instcombine could get. Keeping that logic separate is a big simplifying technique. Most of the code in this pass that isn't in the old one has to do with achieving specific goals: - Updating the dominator tree as we go - Unswitching all cases in a switch in a single step. I think it is still shorter than just the trivial unswitching code in the old pass despite having this functionality. Differential Revision: https://reviews.llvm.org/D32409 llvm-svn: 301576
* [GlobalOpt] Correctly update metadata when localizing a global.Eli Friedman2017-04-271-0/+70
| | | | | | | | | Just calling dropAllReferences leaves pointers to the ConstantExpr behind, so we would eventually crash with a null pointer dereference. Differential Revision: https://reviews.llvm.org/D32551 llvm-svn: 301575
* [PartialInlining]: Improve partial inlining to handle complex conditionsXinliang David Li2017-04-277-7/+315
| | | | | | Differential Revision: http://reviews.llvm.org/D32249 llvm-svn: 301561
* Disable GVN Hoist due to still more bugs being found in it. There isChandler Carruth2017-04-271-1/+1
| | | | | | | | | | also a discussion about exactly what we should do prior to re-enabling it. The current bug is http://llvm.org/PR32821 and the discussion about this is in the review thread for r300200. llvm-svn: 301505
* [LV] Handle external uses of floating-point induction variablesMatthew Simpson2017-04-261-0/+63
| | | | | | | Reference: https://bugs.llvm.org/show_bug.cgi?id=32758 Differential Revision: https://reviews.llvm.org/D32445 llvm-svn: 301428
* [InstCombine] Add test cases for opportunities to improve knownbits handling ↵Craig Topper2017-04-261-0/+26
| | | | | | for cttz and ctlz intrinsics. llvm-svn: 301385
* SimplifyLibCalls: Fix crash on memset(notmalloc())Matthias Braun2017-04-251-0/+9
| | | | | | rdar://31520787 llvm-svn: 301352
* [LV] Make LIT test insensitive to basic block numberingGil Rapaport2017-04-251-12/+12
| | | | | | | | | | | | | This patch is part of D28975's breakdown. induction.ll encodes the specific (and rather arbitrary) numbers given to predicated basic blocks by the unique naming mechanism, which makes it sensitive to changes in LV's instruction generation order. This patch replaces those specific numbers with a numeric pattern. Differential Revision: https://reviews.llvm.org/D32404 llvm-svn: 301345
* Skip bitcasts while looking for GEP in LoadStoreVectorizerStanislav Mekhanoshin2017-04-251-0/+83
| | | | | | Differential Revisison: https://reviews.llvm.org/D32101 llvm-svn: 301343
* [InstCombine] Fix CHECK-LABEL in two tests.Craig Topper2017-04-251-2/+2
| | | | llvm-svn: 301337
* [InstSimplify] Handle (~A & ~B) | (~A ^ B) -> ~A ^ BCraig Topper2017-04-251-0/+62
| | | | | | | | | | The code Sanjay Patel moved over from InstCombine doesn't work properly if the 'and' has both inputs as nots because we used a commuted op matcher on the 'and' first. But this will bind to the first 'not' on 'and' when there could be two 'not's. InstCombine could rely on DeMorgan to ensure the 'and' wouldn't have two 'not's eventually, but InstSimplify can't rely on that. This patch matches the xor first then checks for the ands and allows a not of either operand of the xor. Differential Revision: https://reviews.llvm.org/D32458 llvm-svn: 301329
* [InstCombine] Add missing commute handling to (A | B) & (B ^ (~A)) -> (A & B)Craig Topper2017-04-251-8/+2
| | | | | | | | The matching here wasn't able to handle all the possible commutes. It always assumed the not would be on the left of the xor, but that's not guaranteed. Differential Revision: https://reviews.llvm.org/D32474 llvm-svn: 301316
* [SimplifyLibCalls] Fix infinite loop with fast-math optimization.Andrew Ng2017-04-251-0/+60
| | | | | | | | | | | | | | | | | | One of the fast-math optimizations is to replace calls to standard double functions with their float equivalents, e.g. exp -> expf. However, this can cause infinite loops for the following: float expf(float val) { return (float) exp((double) val); } A similar inline declaration exists in the MinGW-w64 math.h header file which when compiled with -O2/3 and fast-math generates infinite loops. So this fix checks that the calling function to the standard double function that is being replaced does not match the float equivalent. Differential Revision: https://reviews.llvm.org/D31806 llvm-svn: 301304
* [InstCombine] Add test cases for missing commute handling in ((A ^ C) ^ B) & ↵Craig Topper2017-04-251-0/+75
| | | | | | (B ^ A) -> (B ^ A) & ~C llvm-svn: 301297
* [InstCombine] Add test cases showing failures to handle commuted patterns ↵Craig Topper2017-04-251-0/+34
| | | | | | after tricking the operand complexity sorting. llvm-svn: 301296
* [ObjCARC] Do not sink an objc_retain past a clang.arc.use.Akira Hatanaka2017-04-252-7/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to do this to prevent a miscompile which sinks an objc_retain past an objc_release that releases the object objc_retain retains. This happens because the top-down and bottom-up traversals each determines the insert point for retain or release individually without knowing where the other instruction is moved. For example, when the following IR is fed to the ARC optimizer, the top-down traversal decides to insert objc_retain right before objc_release and the bottom-up traversal decides to insert objc_release right after clang.arc.use. (IR before ARC optimizer) %11 = call i8* @objc_retain(i8* %10) call void (...) @clang.arc.use(%0* %5) call void @llvm.dbg.value(...) call void @objc_release(i8* %6) This reverses the order of objc_release and objc_retain, which causes the object to be destructed prematurely. (IR after ARC optimizer) call void (...) @clang.arc.use(%0* %5) call void @objc_release(i8* %6) call void @llvm.dbg.value(...) %11 = call i8* @objc_retain(i8* %10) rdar://problem/30530580 llvm-svn: 301289
* [InstSimplify] use ConstantRange to simplify more and-of-icmpsSanjay Patel2017-04-243-260/+86
| | | | | | | | | | | | | We can simplify (and (icmp X, C1), (icmp X, C2)) to one of the icmps in many cases. I had to check some of these with Alive to prove to myself it's right, but everything seems to check out. Eg, the code in instcombine was completely ignoring predicates with mismatched signedness. Handling or-of-icmps would be a follow-up step. Differential Revision: https://reviews.llvm.org/D32143 llvm-svn: 301260
* Update profile during memory instrinsic optimizationTeresa Johnson2017-04-241-5/+16
| | | | | | | | | | | | | | | | Summary: Ensure that the new merge BB (which contains the rest of the original BB after the mem op being optimized) gets a profile frequency, in case there are additional mem ops later in the BB. Otherwise they get skipped as the merge BB looks cold. Reviewers: davidxl, xur Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32447 llvm-svn: 301244
* Revert "StructurizeCFG: Directly invert cmp instructions"Matt Arsenault2017-04-243-69/+6
| | | | | | | | This reverts commit r300732. This breaks a few tests. I think the problem is related to adding more uses of the condition that don't yet exist at this point. llvm-svn: 301242
* [LoopUnroll] Don't try to unroll non canonical loops.Davide Italiano2017-04-241-0/+26
| | | | | | | | | | | | The current Loop Unroll implementation works with loops having a single latch that contains a conditional branch to a block outside the loop (the other successor is, by defition of latch, the header). If this precondition doesn't hold, avoid unrolling the loop as the code is not ready to handle such circumstances. Differential Revision: https://reviews.llvm.org/D32261 llvm-svn: 301239
* [LIR] Obey non-integral pointer semanticsSanjoy Das2017-04-241-0/+48
| | | | | | | | | | | | | | Summary: See http://llvm.org/docs/LangRef.html#non-integral-pointer-type Reviewers: haicheng Reviewed By: haicheng Subscribers: mcrosier, mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D32196 llvm-svn: 301238
* Handle invariant.group.barrier in BasicAAPiotr Padlewski2017-04-241-5/+7
| | | | | | | | | | | | | | | | | | | | | Summary: llvm.invariant.group.barrier returns pointer that mustalias pointer it takes. It can't be marked with `returned` attribute, because it would be remove easily. The other reason is that only Alias Analysis can know about this, because if any other pass would know it, then the result would be replaced with it's argument, which would be invalid. We can think about returned pointer as something that mustalias, but it doesn't have to be bitwise the same as the argument. Reviewers: dberlin, chandlerc, hfinkel, sanjoy Subscribers: reames, nlewycky, rsmith, anna, amharc Differential Revision: https://reviews.llvm.org/D31585 llvm-svn: 301227
* Revert "Compute safety information in a much finer granularity."Evgeniy Stepanov2017-04-242-82/+14
| | | | | | Use-after-free in llvm::isGuaranteedToExecute. llvm-svn: 301214
* [InstSimplify] move (A & ~B) | (A ^ B) -> (A ^ B) from InstCombineSanjay Patel2017-04-242-53/+53
| | | | | | | | | | | This is a straight cut and paste, but there's a bigger problem: if this fold exists for simplifyOr, there should be a DeMorganized version for simplifyAnd. But more than that, we have a patchwork of ad hoc logic optimizations in InstCombine. There should be some structure to ensure that we're not missing sibling folds across and/or/xor. llvm-svn: 301213
* Use DW_OP_stack_value when reconstructing variable values with arithmetic.Adrian Prantl2017-04-241-7/+35
| | | | | | | | | | | | | | | When the location description of a source variable involves arithmetic on the value itself, it needs to be marked with DW_OP_stack_value since it is not describing the variable's location, but rather its value. This is a follow-up to r297971 and fixes the source testcase quoted in the comment in debuginfo-dce.ll. rdar://problem/30725338 This reapplies r301093 without modifications. llvm-svn: 301210
* InstCombine: Fix assert when reassociating fsub with undefMatt Arsenault2017-04-241-0/+44
| | | | | | | | | | | | | There is logic to track the expected number of instructions produced. It thought in this case an instruction would be necessary to negate the result, but here it folded into a ConstantExpr fneg when the non-undef value operand was cancelled out by the second fsub. I'm not sure why we don't fold constant FP ops with undef currently, but I think that would also avoid this problem. llvm-svn: 301199
* Compute safety information in a much finer granularity.Xin Tong2017-04-242-14/+82
| | | | | | | | | | | | | | | | | | | Summary: Instead of keeping a variable indicating whether there are early exits in the loop. We keep all the early exits. This improves LICM's ability to move instructions out of the loop based on is-guaranteed-to-execute. I am going to update compilation time as well soon. Reviewers: hfinkel, sanjoy, efriedma, mkuper Reviewed By: hfinkel Subscribers: llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D32433 llvm-svn: 301196
* InstCombine/AMDGPU: Fix constant folding of llvm.amdgcn.{icmp,fcmp}Nicolai Haehnle2017-04-241-2/+4
| | | | | | | | | | | | | | | | | | Summary: The return value of these intrinsics should always have 0 bits for inactive threads. This means that when all arguments are constant and the comparison evaluates to true, the intrinsic should return the current exec mask. Fixes some GL_ARB_shader_ballot tests. Reviewers: arsenm Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye Differential Revision: https://reviews.llvm.org/D32344 llvm-svn: 301195
* Revert "[SCEV] Enable SCEV verification by default in EXPENSIVE_CHECKS builds"Sanjoy Das2017-04-241-1/+1
| | | | | | | This reverts commit r301150. It breaks CodeGen/Hexagon/hwloop-wrap2.ll, reverting while I investigate. llvm-svn: 301154
* [SCEV] Enable SCEV verification by default in EXPENSIVE_CHECKS buildsSanjoy Das2017-04-241-1/+1
| | | | llvm-svn: 301150
* [PartialInine]: add triaging optionsXinliang David Li2017-04-231-0/+73
| | | | | | | There are more bugs (runtime failures) triggered when partial inlining is turned on. Add options to help triaging problems. llvm-svn: 301148
* [InstCombine] add/move folds for [not]-xorSanjay Patel2017-04-231-38/+34
| | | | | | | | | | | | We handled all of the commuted variants for plain xor already, although they were scattered around and sometimes folded less efficiently using distributive laws. We had no folds for not-xor. Handling all of these patterns consistently is part of trying to reinstate: https://reviews.llvm.org/rL300977 llvm-svn: 301144
* [InstCombine] add tests for not-xor and remove redundant tests; NFCSanjay Patel2017-04-232-55/+147
| | | | llvm-svn: 301140
* [JumpThread] We want to fold (not thread) when all predecessor go to single ↵Xin Tong2017-04-231-0/+135
| | | | | | | | | | | | | | | | | | | | | BB's successor. Summary: In case all predecessor go to a single successor of current BB. We want to fold (not thread). I failed to update the phi nodes properly in the last patch https://reviews.llvm.org/rL300657. Phi nodes values are per predecessor in LLVM. Reviewers: sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32400 llvm-svn: 301139
* [InstCombine] add tests for or-to-xor; NFCSanjay Patel2017-04-231-0/+76
| | | | llvm-svn: 301131
* [InstCombine] add pattern matches for commuted variants of xor-to-xorSanjay Patel2017-04-231-11/+3
| | | | | | | | | There's probably some better way to write this that eliminates the code duplication without hurting readability, but at least this eliminates the logic holes and is hopefully slightly more efficient than creating new instructions. llvm-svn: 301129
* [InstCombine] add tests for xor-to-xor; NFCSanjay Patel2017-04-231-0/+215
| | | | | | Besides missing 2 commuted patterns, the way we handle these folds is inefficient. llvm-svn: 301128
* [InstCombine] add tests for add-to-xor commuted variants; NFCSanjay Patel2017-04-231-5/+47
| | | | | | | 1 out of the 4 tests commuted the operands, so there's an asymmetry somewhere under this in how we handle these transforms. llvm-svn: 301125
* Revert "Use DW_OP_stack_value when reconstructing variable values with ↵Adrian Prantl2017-04-231-35/+7
| | | | | | | | arithmetic." This reverts commit r301093 while investigating stage2 bot breakage. llvm-svn: 301099
OpenPOWER on IntegriCloud