summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [Guards] Introduce loop-predication passArtur Pilipenko2017-01-253-0/+796
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces guard based loop predication optimization. The new LoopPredication pass tries to convert loop variant range checks to loop invariant by widening checks across loop iterations. For example, it will convert for (i = 0; i < n; i++) { guard(i < len); ... } to for (i = 0; i < n; i++) { guard(n - 1 < len); ... } After this transformation the condition of the guard is loop invariant, so loop-unswitch can later unswitch the loop by this condition which basically predicates the loop by the widened condition: if (n - 1 < len) for (i = 0; i < n; i++) { ... } else deoptimize This patch relies on an NFC change to make ScalarEvolution::isMonotonicPredicate public (revision 293062). Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D29034 llvm-svn: 293064
* [InstCombine] Canonicalize guards for NOT OR conditionArtur Pilipenko2017-01-251-0/+26
| | | | | | | | | | | | This is a partial fix for Bug 31520 - [guards] canonicalize guards in instcombine Reviewed By: apilipenko Differential Revision: https://reviews.llvm.org/D29075 Patch by Maxim Kazantsev. llvm-svn: 293061
* [InstCombine][SSE] Add support for PACKSS/PACKUS constant foldingSimon Pilgrim2017-01-251-38/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D28949 llvm-svn: 293060
* [InstCombine] Canonicalize guards for AND conditionArtur Pilipenko2017-01-251-0/+20
| | | | | | | | | | | | This is a partial fix for Bug 31520 - [guards] canonicalize guards in instcombine Reviewed By: apilipenko Differential Revision: https://reviews.llvm.org/D29074 Patch by Maxim Kazantsev. llvm-svn: 293058
* [InstCombine] Allow InstrCombine to remove one of adjacent guards if they ↵Artur Pilipenko2017-01-251-0/+30
| | | | | | | | | | | | | | are equivalent This is a partial fix for Bug 31520 - [guards] canonicalize guards in instcombine Reviewed By: majnemer, apilipenko Differential Revision: https://reviews.llvm.org/D29071 Patch by Maxim Kazantsev. llvm-svn: 293056
* [SLP] Improve horizontal vectorization for non-power-of-2 number ofAlexey Bataev2017-01-251-98/+72
| | | | | | | | | | | | | instructions. If number of instructions in horizontal reduction list is not power of 2 then only PowerOf2Floor(NumberOfInstructions) last elements are actually vectorized, other instructions remain scalar. Patch tries to vectorize the remaining elements either. Differential Revision: https://reviews.llvm.org/D28959 llvm-svn: 293042
* Mark @llvm.powi.* as safe to speculatively execute.whitequark2017-01-251-1/+4
| | | | | | | | | | | | Floating point intrinsics in LLVM are generally not speculatively executed, since most of them are defined to behave the same as libm functions, which set errno. However, the @llvm.powi.* intrinsics do not correspond to any libm function, and lacks any defined error handling semantics in LangRef. It most certainly does not alter errno. llvm-svn: 293041
* [X86] enable memory interleaving for X86\SLM arch. Mohammed Agabaria2017-01-251-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D28547 llvm-svn: 293040
* [SimplifyCFG] Do not sink and merge inline-asm instructions.Akira Hatanaka2017-01-251-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Conservatively disable sinking and merging inline-asm instructions as doing so can potentially create arguments that cannot satisfy the inline-asm constraints. For example, SimplifyCFG used to do the following transformation: (before) if.then: %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 8) br label %if.end if.else: %1 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 6) br label %if.end (after) %.sink = select i1 %tobool, i32 6, i32 8 %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 %.sink) This would result in a crash in the backend since only immediate integer operands are permitted for constraint "n". rdar://problem/30110806 Differential Revision: https://reviews.llvm.org/D29111 llvm-svn: 293025
* [InstCombine] Added regression test to narrow-swich.llGerolf Hoflehner2017-01-251-0/+42
| | | | llvm-svn: 293018
* [PM] Teach LoopUnroll to update the LPM infrastructure as it unrollsChandler Carruth2017-01-2517-1/+174
| | | | | | | | | | | | | | | | | | | loops. We do this by reconstructing the newly added loops after the unroll completes to avoid threading pass manager details through all the mess of the unrolling infrastructure. I've enabled some extra assertions in the LPM to try and catch issues here and enabled a bunch of unroller tests to try and make sure this is sane. Currently, I'm manually running loop-simplify when needed. That should go away once it is folded into the LPM infrastructure. Differential Revision: https://reviews.llvm.org/D28848 llvm-svn: 293011
* [coroutines] Spill the result of the invoke instruction correctlyGor Nishanov2017-01-251-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we decide that the result of the invoke instruction need to be spilled, we need to insert the spill into a block that is on the normal edge coming out of the invoke instruction. (Prior to this change the code would insert the spill immediately after the invoke instruction, which breaks the IR, since invoke is a terminator instruction). In the following example, we will split the edge going into %cont and insert the spill there. ``` %r = invoke double @print(double 0.0) to label %cont unwind label %pad cont: %0 = call i8 @llvm.coro.suspend(token none, i1 false) switch i8 %0, label %suspend [i8 0, label %resume i8 1, label %cleanup] resume: call double @print(double %r) ``` Reviewers: majnemer Reviewed By: majnemer Subscribers: mehdi_amini, llvm-commits, EricWF Differential Revision: https://reviews.llvm.org/D29102 llvm-svn: 293006
* Explicitly promote indirect calls before sample profile annotation.Dehao Chen2017-01-242-0/+39
| | | | | | | | | | | | | | Summary: In iterative sample pgo where profile is collected from PGOed binary, we may see indirect call targets promoted and inlined in the profile. Before profile annotation, we need to make this happen in order to annotate correctly on IR. This patch explicitly promotes these indirect calls and inlines them before profile annotation. Reviewers: xur, davidxl Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29040 llvm-svn: 292979
* Remove the load hoisting code of MLSM, it is completely subsumed by GVNHoistDaniel Berlin2017-01-242-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GVNHoist performs all the optimizations that MLSM does to loads, in a more general way, and in a faster time bound (MLSM is N^3 in most cases, N^4 in a few edge cases). This disables the load portion. Note that the way ld_hoist_st_sink.ll is written makes one think that the loads should be moved to the while.preheader block, but 1. Neither MLSM nor GVNHoist do it (they both move them to identical places). 2. MLSM couldn't possibly do it anyway, as the while.preheader block is not the head of the diamond, while.body is. (GVNHoist could do it if it was legal). 3. At a glance, it's not legal anyway because the in-loop load conflict with the in-loop store, so the loads must stay in-loop. I am happy to update the test to use update_test_checks so that checking is tighter, just was going to do it as a followup. Note that i can find no particular benefit to the store portion on any real testcase/benchmark i have (even size-wise). If we really still want it, i am happy to commit to writing a targeted store sinker, just taking the code from the MemorySSA port of MergedLoadStoreMotion (which is N^2 worst case, and N most of the time). We can do what it does in a much better time bound. We also should be both hoisting and sinking stores, not just sinking them, anyway, since whether we should hoist or sink to merge depends basically on luck of the draw of where the blockers are placed. Nonetheless, i have left it alone for now. Reviewers: chandlerc, davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29079 llvm-svn: 292971
* [InstSimplify] try to eliminate icmp Pred (add nsw X, C1), C2Sanjay Patel2017-01-241-21/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was surprised to see that we're missing icmp folds based on 'add nsw' in InstCombine, but we should handle the InstSimplify cases first because that could make the InstCombine code simpler. Here are Alive-based proofs for the logic: Name: add_neg_constant Pre: C1 < 0 && (C2 > ((1<<(width(C1)-1)) + C1)) %a = add nsw i7 %x, C1 %b = icmp sgt %a, C2 => %b = false Name: add_pos_constant Pre: C1 > 0 && (C2 < ((1<<(width(C1)-1)) + C1 - 1)) %a = add nsw i6 %x, C1 %b = icmp slt %a, C2 => %b = false Name: nuw Pre: C1 u>= C2 %a = add nuw i11 %x, C1 %b = icmp ult %a, C2 => %b = false Differential Revision: https://reviews.llvm.org/D29053 llvm-svn: 292952
* [PH] Replace uses of AssertingVH from members of analysis results withChandler Carruth2017-01-242-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a lazy-asserting PoisoningVH. AssertVH is fundamentally incompatible with cache-invalidation of analysis results. The invaliadtion happens after the AssertingVH has already fired. Instead, use a PoisoningVH that will assert if the dangling handle is ever used rather than merely be assigned or destroyed. This patch also removes all of the (numerous) doomed attempts to work around this fundamental incompatibility. It is a pretty significant simplification IMO. The most interesting change is in the Inliner where we still do some clearing because we don't want to rely on the coarse grained invalidation strategy of the containing pass manager. However, I prefer the approach that contains this logic to the cleanup phase of the Inliner, and I think we could enhance the CGSCC analysis management layer to make this even better in the future if desired. The rest is straight cleanup. I've also added a test for one of the harder cases to work around: when a *module analysis* contains many AssertingVHes pointing at functions. Differential Revision: https://reviews.llvm.org/D29006 llvm-svn: 292928
* [SLP] Additional test for checking that instruction with extra args isAlexey Bataev2017-01-241-0/+57
| | | | | | not reconstructed. llvm-svn: 292911
* Update domtree incrementally in loop peeling.Serge Pavlov2017-01-241-1/+1
| | | | | | | | | With this change dominator tree remains in sync after each step of loop peeling. Differential Revision: https://reviews.llvm.org/D29029 llvm-svn: 292895
* SimplifyLibCalls: Replace more unary libcalls with intrinsicsMatt Arsenault2017-01-233-123/+276
| | | | llvm-svn: 292855
* [LoopUnroll] First form LCSSA, then loop-simplifyMichael Kuperstein2017-01-231-0/+55
| | | | | | | | | | | | | Running non-LCSSA-preserving LoopSimplify followed by LCSSA on (roughly) the same loop is incorrect, since LoopSimplify may break LCSSA arbitrarily higher in the loop nest. Instead, run LCSSA first, and then run LCSSA-preserving LoopSimplify on the result. This fixes PR31718. Differential Revision: https://reviews.llvm.org/D29055 llvm-svn: 292854
* [InstSimplify] add tests to show missing folds from 'icmp (add nsw)'; NFCSanjay Patel2017-01-231-0/+169
| | | | llvm-svn: 292841
* [SLP] Additional test with extra args in horizontal reductions.Alexey Bataev2017-01-231-0/+63
| | | | llvm-svn: 292821
* [MemorySSA] Add new tests for invariant.groupsPiotr Padlewski2017-01-231-0/+182
| | | | | | | | | | | | | | | | | Summary: Next round of extra tests for MSSA. I have a prototype invariant.group handling implementation that fixes all the FIXMEs, and I think it will be easier to see what is the difference if I firstly post this, and then only fix fixits. Reviewers: george.burgess.iv, dberlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29022 llvm-svn: 292797
* [InstCombine][X86] Add MULDQ/MULUDQ constant folding supportSimon Pilgrim2017-01-231-24/+12
| | | | llvm-svn: 292793
* [InstCombine][X86] MULDQ/MULUDQ undef -> zeroSimon Pilgrim2017-01-231-6/+6
| | | | | | Match generic mul behaviour so that <X x i64> multiply and muldq/muludq pattern act the same llvm-svn: 292784
* [SLP] Additional test for SLP vectorizer with 31 reduction elements.Alexey Bataev2017-01-231-0/+196
| | | | llvm-svn: 292783
* [InstCombine][SSE] Tests showing missed opportunities to constant fold ↵Simon Pilgrim2017-01-231-0/+58
| | | | | | PMULDQ/PMULUDQ llvm-svn: 292782
* This test apparently requires an x86 target and is failing on numerousChandler Carruth2017-01-231-0/+48
| | | | | | | | | | | bots ever since d0k fixed the CHECK lines so that it did something at all. It isn't actually testing SCEV directly but LSR, so move it into LSR and the x86-specific tree of tests that already exists there. Target dependence is common and unavoidable with the current design of LSR. llvm-svn: 292774
* [PM] Replace the hard invalidate in JumpThreading for LVI with correctChandler Carruth2017-01-231-0/+4
| | | | | | | | | | | | | | | | | | | | | invalidation of deleted functions in GlobalDCE. This was always testing a bug really triggered in GlobalDCE. Right now we have analyses with asserting value handles into IR. As long as those remain, when *deleting* an IR unit, we cannot wait for the normal invalidation scheme to kick in even though it was designed to work correctly in the face of these kinds of deletions. Instead, the pass needs to directly handle invalidating the analysis results pointing at that IR unit. I've tought the Inliner about this and this patch teaches GlobalDCE. This will handle the asserting VH case in the existing test as well as other issues of the same fundamental variety. I've moved the test into the GlobalDCE directory and added a comment explaining what is going on. Note that we cannot simply require LVI here because LVI is too lazy. llvm-svn: 292773
* [PM] Add a dedicated test case for the issue fixed in r292770.Chandler Carruth2017-01-231-0/+33
| | | | | | | | While this is covered by a clang test case, we should have something locally to LLVM that immediately checks the inliner doesn't leave analyses to dangling IR bodies. llvm-svn: 292772
* Fix some broken CHECK lines.Benjamin Kramer2017-01-225-7/+7
| | | | | | The colon is important. llvm-svn: 292761
* [PM] Fix a really nasty bug introduced when adding PGO support to theChandler Carruth2017-01-221-0/+111
| | | | | | | | | | | | | | | | | | | | | new PM's inliner. The bug happens when we refine an SCC after having computed a proxy for the FunctionAnalysisManager, and then proceed to compute fresh analyses for functions in the *new* SCC using the manager provided by the old SCC's proxy. *And* when we manage to mutate a function in this new SCC in a way that invalidates those analyses. This can be... challenging to reproduce. I've managed to contrive a set of functions that trigger this and added a test case, but it is a bit brittle. I've directly checked that the passes run in the expected ways to help avoid the test just becoming silently irrelevant. This gets the new PM back to passing the LLVM test suite after the PGO improvements landed. llvm-svn: 292757
* [MemorySSA] Remove deprecated comment from testPiotr Padlewski2017-01-211-3/+0
| | | | llvm-svn: 292733
* [MemorySSA] Fix invariant.group test and add newPiotr Padlewski2017-01-211-2/+75
| | | | | | | | | | | | | | | | | | Summary: This test had a bug: !llvm.invariant.group instead of !invariant.group. Also add some new test for future development. All tests passes, when MSSA will support invariant.group only the lines with FIXIT should be changed. Reviewers: dberlin, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28969 llvm-svn: 292730
* [InstCombine] use m_APInt to allow ashr folds for vectors with splat constantsSanjay Patel2017-01-211-6/+2
| | | | | | | We may be able to assert that no shl-shl or lshr-lshr pairs ever get here because we should have already handled those in foldShiftedShift(). llvm-svn: 292726
* [InstCombine] add tests for ashr-ashr; NFCSanjay Patel2017-01-211-6/+47
| | | | llvm-svn: 292724
* [PM] Teach the loop PM to run LoopSimplify prior to the loop pipeline.Chandler Carruth2017-01-212-2/+4
| | | | | | | | | | | | | | | This adds the last remaining core feature of the loop pass pipeline in the new PM and removes the last of the really egregious hacks in the LICM tests. Sadly, this requires really substantial changes in the unittests in order to provide and maintain simplified loops. This is particularly hard because for example LoopSimplify will try to fold undef branches to an ideal direction and simplify the loop accordingly. Differential Revision: https://reviews.llvm.org/D28766 llvm-svn: 292709
* MergeFunctions: Preserve debug info in thunks, under option ↵Anmol P. Paralkar2017-01-211-0/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -mergefunc-preserve-debug-info Summary: Under option -mergefunc-preserve-debug-info we: - Do not create a new function for a thunk. - Retain the debug info for a thunk's parameters (and associated instructions for the debug info) from the entry block. Note: -debug will display the algorithm at work. - Create debug-info for the call (to the shared implementation) made by a thunk and its return value. - Erase the rest of the function, retaining the (minimally sized) entry block to create a thunk. - Preserve a thunk's call site to point to the thunk even when both occur within the same translation unit, to aid debugability. Note that this behaviour differs from the underlying -mergefunc implementation which modifies the thunk's call site to point to the shared implementation when both occur within the same translation unit. Reviewers: echristo, eeckstein, dblaikie, aprantl, friss Reviewed By: aprantl Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D28075 llvm-svn: 292702
* [ConstantFold] Remove test checking that we don't constant-fold sqrt(-2).Justin Lebar2017-01-211-9/+0
| | | | | | | This depended on libm's errno behavior (we constant fold iff libm's sqrt(-2) does not set errno) and was breaking on mac. llvm-svn: 292701
* [ConstantFolding] Constant-fold llvm.sqrt(x) like other intrinsics.Justin Lebar2017-01-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently we return undef, but we're in the process of changing the LangRef so that llvm.sqrt behaves like the other math intrinsics, matching the return value of the standard libcall but not setting errno. This change is legal even without the LangRef change because currently calling llvm.sqrt(x) where x is negative is spec'ed to be UB. But in practice it's also safe because we're simply constant-folding fewer inputs: Inputs >= -0 get constant-folded as before, but inputs < -0 now aren't constant-folded, because ConstantFoldFP aborts if the host math function raises an fp exception. Reviewers: hfinkel, efriedma, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28929 llvm-svn: 292692
* [InstCombine] auto-generate checks; NFCSanjay Patel2017-01-202-34/+75
| | | | llvm-svn: 292682
* LowerTypeTests: Simplify; always create SizeM1 with type IntPtrTy, move ↵Peter Collingbourne2017-01-203-6/+6
| | | | | | initialization out of if statement. llvm-svn: 292674
* Add indirect call promotion to SamplePGODehao Chen2017-01-202-0/+22
| | | | | | | | | | | | | | Summary: This patch adds metadata for indirect call promotion in the sample profile loader. Reviewers: xur, davidxl, dnovillo Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28923 llvm-svn: 292672
* Improve PGO support for the new inlinerEaswaran Raman2017-01-207-2/+272
| | | | | | | | | | | | | | | | | | | | | | | | This adds the following to the new PM based inliner in PGO mode: * Use block frequency analysis to derive callsite's profile count and use that to adjust thresholds of hot and cold callsites. * Incrementally update the BFI of the caller after a callee gets inlined into it. This incremental update is only within an invocation of the run method - BFI is not preserved across calls to run. Update the function entry count of the callee after inlining it into a caller. * I've tuned the thresholds for the hot and cold callsites using a hacked up version of the old inliner that explicitly computes BFI on a set of internal benchmarks and spec. Once the new PM based pipeline stabilizes (IIRC Chandler mentioned there are known issues) I'll benchmark this again and adjust the thresholds if required. Inliner PGO support. Differential revision: https://reviews.llvm.org/D28331 llvm-svn: 292666
* [ValueTracking] recognize variations of 'clamp' to improve codegen (PR31693)Sanjay Patel2017-01-201-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By enhancing value tracking, we allow an existing min/max canonicalization to kick in and improve codegen for several targets that have min/max instructions. Unfortunately, recognizing min/max in value tracking may cause us to hit a hack in InstCombiner::visitICmpInst() more often: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html ...but I'm hoping we can remove that soon. Correctness proofs based on Alive: Name: smaxmin Pre: C1 < C2 %cmp2 = icmp slt i8 %x, C2 %min = select i1 %cmp2, i8 %x, i8 C2 %cmp3 = icmp slt i8 %x, C1 %r = select i1 %cmp3, i8 C1, i8 %min => %cmp2 = icmp slt i8 %x, C2 %min = select i1 %cmp2, i8 %x, i8 C2 %cmp1 = icmp sgt i8 %min, C1 %r = select i1 %cmp1, i8 %min, i8 C1 Name: sminmax Pre: C1 > C2 %cmp2 = icmp sgt i8 %x, C2 %max = select i1 %cmp2, i8 %x, i8 C2 %cmp3 = icmp sgt i8 %x, C1 %r = select i1 %cmp3, i8 C1, i8 %max => %cmp2 = icmp sgt i8 %x, C2 %max = select i1 %cmp2, i8 %x, i8 C2 %cmp1 = icmp slt i8 %max, C1 %r = select i1 %cmp1, i8 %max, i8 C1 ---------------------------------------- Optimization: smaxmin Done: 1 Optimization is correct! ---------------------------------------- Optimization: sminmax Done: 1 Optimization is correct! Name: umaxmin Pre: C1 u< C2 %cmp2 = icmp ult i8 %x, C2 %min = select i1 %cmp2, i8 %x, i8 C2 %cmp3 = icmp ult i8 %x, C1 %r = select i1 %cmp3, i8 C1, i8 %min => %cmp2 = icmp ult i8 %x, C2 %min = select i1 %cmp2, i8 %x, i8 C2 %cmp1 = icmp ugt i8 %min, C1 %r = select i1 %cmp1, i8 %min, i8 C1 Name: uminmax Pre: C1 u> C2 %cmp2 = icmp ugt i8 %x, C2 %max = select i1 %cmp2, i8 %x, i8 C2 %cmp3 = icmp ugt i8 %x, C1 %r = select i1 %cmp3, i8 C1, i8 %max => %cmp2 = icmp ugt i8 %x, C2 %max = select i1 %cmp2, i8 %x, i8 C2 %cmp1 = icmp ult i8 %max, C1 %r = select i1 %cmp1, i8 %max, i8 C1 ---------------------------------------- Optimization: umaxmin Done: 1 Optimization is correct! ---------------------------------------- Optimization: uminmax Done: 1 Optimization is correct! llvm-svn: 292660
* [InstCombine] add tests to show missed canonicalization of min/max; NFCSanjay Patel2017-01-201-0/+71
| | | | | | | | | | | Unfortunately, recognizing these in value tracking may cause us to hit a hack in InstCombiner::visitICmpInst() more often: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html ...but besides being the obviously Right Thing To Do, there's a clear codegen win from identifying these patterns for several targets. llvm-svn: 292655
* LowerTypeTests: Implement importing of type identifiers.Peter Collingbourne2017-01-202-0/+201
| | | | | | | | | To import a type identifier we read the summary and create external references to the symbols defined when exporting. Differential Revision: https://reviews.llvm.org/D28546 llvm-svn: 292654
* NewGVN: Remove pr31686.ll, it is tested by pr31594.ll, which is much smaller ↵Daniel Berlin2017-01-201-2016/+0
| | | | | | and simpler llvm-svn: 292649
* NewGVN: Fix PR 31686 and PR 31698 by rewriting store leader handling.Daniel Berlin2017-01-204-1/+2049
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This rewrites store expression/leader handling. We no longer use the value operand as the leader, instead, we store it separately. We also now store the stored value as part of the expression, and compare it when comparing stores for equality. This enables us to get rid of a bunch of our previous hacks and machinations, as the existing machinery takes care of everything *except* updating the stored value on classes. The only time we have to update it is if the storecount goes to 0, and when we do, we destroy it. Since we no longer use the value operand as the leader, during elimination, we have to use the value operand. Doing this also fixes a bunch of store forwarding cases we were missing. Any value operand we use is guaranteed to either be updated by previous eliminations, or minimized by future ones. (IE the fact that we don't use the most dominating value operand when it's not a constant does not affect anything). Sadly, this change also exposes that we didn't pay attention to the output of the pr31594.ll test, as it also very clearly exposes the same store leader bug we are fixing here. (I added pr31682.ll anyway, but maybe we think that's too large to be useful) On the plus side, propagate-ir-flags.ll now passes due to the corrected store forwarding. This change was 3 stage'd on darwin and linux, with the full test-suite. Reviewers: davide Subscribers: llvm-commits llvm-svn: 292648
* Recommit "[InlineCost] Use TTI to check if GEP is free." #3Haicheng Wu2017-01-202-0/+32
| | | | | | | | | | | | This is the third attemp to recommit r292526. The original summary: Currently, a GEP is considered free only if its indices are all constant. TTI::getGEPCost() can give target-specific more accurate analysis. TTI is already used for the cost of many other instructions. llvm-svn: 292633
OpenPOWER on IntegriCloud