summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-2711-36/+28
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [LoopInterchange] Preserve LCSSA.Florian Hahn2018-09-261-18/+54
| | | | | | | | | | | | | | | | | | This patch extends LoopInterchange to move LCSSA to the right place after interchanging. This is required for LoopInterchange to become a function pass. An alternative to the manual moving of the PHIs, we could also re-form the LCSSA phis for a set of interchanged loops, but that's more expensive. Reviewers: efriedma, mcrosier, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D52154 llvm-svn: 343132
* Revert "Revert "[ConstHoist] Do not rebase single (or few) dependent constant""Zhaoshi Zheng2018-09-261-22/+46
| | | | | | | | | | | | | | | | | | | This reverts commit bd7b44f35ee9fbe365eb25ce55437ea793b39346. Reland r342994: disabled the optimization and explicitly enable it in test. -mllvm -consthoist-min-num-to-rebase<unsigned>=0 [ConstHoist] Do not rebase single (or few) dependent constant If an instance (InsertionPoint or IP) of Base constant A has only one or few rebased constants depending on it, do NOT rebase. One extra ADD instruction is required to materialize each rebased constant, assuming A and the rebased have the same materialization cost. Differential Revision: https://reviews.llvm.org/D52243 llvm-svn: 343053
* Revert "[ConstHoist] Do not rebase single (or few) dependent constant"Jessica Paquette2018-09-251-46/+22
| | | | | | | | | | | | | This caused a couple test failures on a bot: CodeGen/X86/constant-hoisting-bfi.ll Transforms/ConstantHoisting/X86/ehpad.ll Example: http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/53575/ llvm-svn: 343005
* [ConstHoist] Do not rebase single (or few) dependent constantZhaoshi Zheng2018-09-251-22/+46
| | | | | | | | | | | If an instance (InsertionPoint or IP) of Base constant A has only one or few rebased constants depending on it, do NOT rebase. One extra ADD instruction is required to materialize each rebased constant, assuming A and the rebased have the same materialization cost. Differential Revision: https://reviews.llvm.org/D52243 llvm-svn: 342994
* Re-submitting changes in D51550 because it failed to patch.Christy Lee2018-09-241-28/+57
| | | | | | | | | | | | Reviewers: javed.absar, trentxintong, courbet Reviewed By: trentxintong Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52433 llvm-svn: 342919
* revert changes from r342722Sameer Sahasrabuddhe2018-09-211-1/+0
| | | | | | | | | "[AMDGPU] lower-switch in preISel as a workaround for legacy DA" This broke regression tests. The first breakage was noticed here: http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/23549 llvm-svn: 342743
* [AMDGPU] lower-switch in preISel as a workaround for legacy DASameer Sahasrabuddhe2018-09-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The default target of the switch instruction may sometimes be an "unreachable" block, when it is guaranteed that one of the cases is always taken. The dominator tree concludes that such a switch instruction does not have an immediate post dominator. This confuses divergence analysis, which is unable to propagate sync dependence to the targets of the switch instruction. As a workaround, the AMDGPU target now invokes lower-switch as a preISel pass. LowerSwitch is designed to handle the unreachable default target correctly, allowing the divergence analysis to locate the correct immediate dominator of the now-lowered switch. Reviewers: arsenm, nhaehnle Reviewed By: nhaehnle Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits, simoll Differential Revision: https://reviews.llvm.org/D52221 llvm-svn: 342722
* Merge clang's isRepeatedBytePattern with LLVM's isBytewiseValueJF Bastien2018-09-212-1/+11
| | | | | | | | | | | | | Summary: his code was in CGDecl.cpp and really belongs in LLVM's isBytewiseValue. Teach isBytewiseValue the tricks clang's isRepeatedBytePattern had, including merging undef properly, and recursing on more types. clang part of this patch: D51752 Subscribers: dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51751 llvm-svn: 342709
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-201-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
* [IPSCCP] Fix a problem with removing labels in a switch with undef conditionBjorn Pettersson2018-09-201-25/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before removing basic blocks that ipsccp has considered as dead all uses of the basic block label must be removed. That is done by calling ConstantFoldTerminator on the users. An exception is when the branch condition is an undef value. In such scenarios ipsccp is using some internal assumptions regarding which edge in the control flow that should remain, while ConstantFoldTerminator don't know how to fold the terminator. The problem addressed here is related to ConstantFoldTerminator's ability to rewrite a 'switch' into a conditional 'br'. In such situations ConstantFoldTerminator returns true indicating that the terminator has been rewritten. However, ipsccp treated the true value as if the edge to the dead basic block had been removed. So the code for resolving an undef branch condition did not trigger, and we ended up with assertion that there were uses remaining when deleting the basic block. The solution is to resolve indeterminate branches before the call to ConstantFoldTerminator. Reviewers: efriedma, fhahn, davide Reviewed By: fhahn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52232 llvm-svn: 342632
* Temporarily Revert "[New PM] Introducing PassInstrumentation framework"Eric Christopher2018-09-201-10/+0
| | | | | | | | as it was causing failures in the asan buildbot. This reverts commit r342597. llvm-svn: 342616
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342597
* Revert rL342544: [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-191-10/+0
| | | | | | A bunch of bots fail to compile unittests. Reverting. llvm-svn: 342552
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342544
* Do not optimize atomic load to non-atomic memcmpChristy Lee2018-09-181-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D51998 llvm-svn: 342498
* [LLVM-C][OCaml] Add UnifyFunctionExitNodes pass to C and OCaml APIswhitequark2018-09-181-0/+5
| | | | | | | | | | | | | | | | Summary: Adds LLVMAddUnifyFunctionExitNodesPass to expose createUnifyFunctionExitNodesPass to the C and OCaml APIs. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52212 llvm-svn: 342476
* [LLVM-C][OCaml] Add LowerAtomic pass to C and OCaml APIswhitequark2018-09-181-0/+4
| | | | | | | | | | | | | | | | Summary: Adds LLVMAddLowerAtomicPass to expose createLowerAtomicPass in the C and OCaml APIs. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52211 llvm-svn: 342475
* [IndVars] Remove unreasonable checks in rewriteLoopExitValuesMax Kazantsev2018-09-181-11/+5
| | | | | | | | | | | A piece of logic in rewriteLoopExitValues has a weird check on number of users which allowed an unprofitable transform in case if an instruction has more than 6 users. Differential Revision: https://reviews.llvm.org/D51404 Reviewed By: etherzhhb llvm-svn: 342444
* [EarlyCSEwMemorySSA] Add MSSA verification and tests to make EarlyCSE ↵Alina Sbirlea2018-09-171-0/+2
| | | | | | | | | | | | | | | | | failures easier to track. Summary: EarlyCSE can make IR changes that will leave MemorySSA with accesses claiming to be optimized, but for which a subsequent MemorySSA run will yield a different optimized result. Due to relying on AA queries, we can't fix this in general, unless we recompute MemorySSA. Adding some tests to track this and a basic verify for future potential failures. Reviewers: george.burgess.iv, gberry Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D51960 llvm-svn: 342422
* [NFC] Turn unsigned counters into boolean flagsMax Kazantsev2018-09-171-8/+13
| | | | llvm-svn: 342360
* [LoopInterchange] Preserve ScalarEvolution, by forgetting about interchanged ↵Florian Hahn2018-09-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | loops. As preparation for LoopInterchange becoming a loop pass, it needs to preserve ScalarEvolution. Even though interchanging should not change the trip count of the loop, it modifies loop entry, latch and exit blocks. I added -verify-scev to some loop interchange tests, but the verification does not catch problems caused by missing invalidation of SE in loop interchange, as the trip counts themselves do not change. So there might be potential to make the SE verification covering more stuff in the future. Reviewers: mkazantsev, efriedma, karthikthecool Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D52026 llvm-svn: 342209
* [NFC] Remove meaningless code from GVNMax Kazantsev2018-09-141-6/+0
| | | | llvm-svn: 342202
* [PartiallyInlineLibCalls] Add DebugCounter supportGeorge Burgess IV2018-09-131-0/+6
| | | | | | | | | | | This adds DebugCounter support to the PartiallyInlineLibCalls pass, which should make debugging/automated bisection easier in the future. Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D50093 llvm-svn: 342172
* [DCE] Add DebugCounter supportGeorge Burgess IV2018-09-131-0/+8
| | | | | | | | Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D50092 llvm-svn: 342170
* revert r341288 - [Reassociate] swap binop operands to increase factoring ↵Sanjay Patel2018-09-121-64/+0
| | | | | | | | potential This causes or exposes indeterminism that is visible in the output of -reassociate. llvm-svn: 342083
* [GVNHoist] computeInsertionPoints() miscalculates IDFAlexandros Lamprineas2018-09-121-4/+2
| | | | | | | | | | | | | | Fix for https://bugs.llvm.org/show_bug.cgi?id=38912. In GVNHoist::computeInsertionPoints() we iterate over the Value Numbers and calculate the Iterated Dominance Frontiers without clearing the IDFBlocks vector first. IDFBlocks ends up accumulating an insane number of basic blocks, which bloats the compilation time of SemaChecking.cpp with ubsan enabled. Differential Revision: https://reviews.llvm.org/D51980 llvm-svn: 342055
* Update MemorySSA in LoopUnswitch.Alina Sbirlea2018-09-111-10/+60
| | | | | | | | | | | | Summary: Update MemorySSA in old LoopUnswitch pass. Actual dependency and update is disabled by default. Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D45301 llvm-svn: 341984
* [CallSiteSplitting] Add debug location to created PHI nodes.Florian Hahn2018-09-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | There are 2 cases when we create PHI nodes: * For the result of the call that was duplicated in the split blocks. Those PHI nodes should have the debug location of the call. * For values produced before the call. Those instructions need to be duplicated in the split blocks and the PHI nodes should have the debug locations of those instructions. Fixes PR37962. Reviewers: junbuml, gbedwell, vsk Reviewed By: junbuml Tags: #debug-info Differential Revision: https://reviews.llvm.org/D51919 llvm-svn: 341970
* [LICM] Avoid duplicate work during building AliasSetTrackerSerguei Katkov2018-09-111-8/+6
| | | | | | | | | | | | | | | | | | Currently we re-use cached info from sub loops or traverse them to populate AliasSetTracker. But after that we traverse all basic blocks from the current loop. This is redundant work. All what we need is traversing the all basic blocks from the loop except those which are used to get the data from the cache. This should improve compile time only. Reviewers: mkazantsev, reames, kariddi, anna Reviewed By: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51715 llvm-svn: 341896
* [IndVars][NFC] Refactor to make modifications of Changed transparentMax Kazantsev2018-09-111-44/+47
| | | | | | | | | | | | | | | | | IndVarSimplify's design is somewhat odd in the way how it reports that some transform has made a change. It has a `Changed` field which can be set from within any function, which makes it hard to track whether or not it was set properly after a transform was made. It leads to oversights in setting this flag where needed, see example in PR38855. This patch removes the `Changed` field, turns it into a local and unifies the signatures of all relevant transform functions to return boolean value which designates whether or not this transform has made a change. Differential Revision: https://reviews.llvm.org/D51850 Reviewed By: skatkov llvm-svn: 341893
* [LICM] (re-)simplify code using MemoryLocation API [NFC]Philip Reames2018-09-111-10/+2
| | | | | | I'd made exactly this same change before, but it appears to have been accidentally reverted in another change. (I'm assuming accidental since it was without comment or test case, and in an unrelated change.) llvm-svn: 341892
* add flag instead of using a constant [NFC]Sebastian Pop2018-09-101-1/+5
| | | | llvm-svn: 341837
* make flag name more specific to gvn [NFC]Sebastian Pop2018-09-101-2/+2
| | | | llvm-svn: 341836
* [GVN] Invalidate cached info for values replaced by equality propagationJohn Brawn2018-09-101-0/+6
| | | | | | | | | When GVN propagates an equality by replacing one value with another it also needs to invalidate the cached information for the value being replaced. Differential Revision: https://reviews.llvm.org/D51218 llvm-svn: 341820
* [IndVars] Set Changed if rewriteFirstIterationLoopExitValues changes IR. PR38863Max Kazantsev2018-09-101-3/+6
| | | | | | | | | | | Currently, `rewriteFirstIterationLoopExitValues` does not set Changed flag even if it makes changes in the IR. There is no clear evidence that it can cause a crash, but it looks highly suspicious and likely invalid. Differential Revision: https://reviews.llvm.org/D51779 Reviewed By: skatkov llvm-svn: 341779
* [IndVars] Set Changed if sinkUnusedInvariants changes IR. PR38863Max Kazantsev2018-09-101-5/+9
| | | | | | | | | | | Currently, `sinkUnusedInvariants` does not set Changed flag even if it makes changes in the IR. There is no clear evidence that it can cause a crash, but it looks highly suspicious and likely invalid. Differential Revision: https://reviews.llvm.org/D51777 Reviewed By: skatkov llvm-svn: 341777
* [SimplifyIndVar] Avoid generating truncate instructions with non-hoisted ↵Abderrazek Zaafrani2018-09-071-0/+152
| | | | | | | | Laod operand. Differential Revision: https://reviews.llvm.org/D49151 llvm-svn: 341726
* NFC: remove magic bool in LoopIdiomRecognizeJF Bastien2018-09-071-9/+9
| | | | | | Use an enum class instead. llvm-svn: 341684
* [NewGVN] Mark function as changed if we erase instructions.Florian Hahn2018-09-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | Currently eliminateInstructions only returns true if any instruction got replaced. In the test case for this patch, we eliminate the trivially dead calls, for which eliminateInstructions not do a replacement and the function is not marked as changed, which is why the inliner crashes while traversing the call graph. Alternatively we could also change eliminateInstructions to return true in case we mark instructions for deletion, but that's slightly more code and doing it at the place where the replacement happens seems safer. Fixes PR37517. Reviewers: davide, mcrosier, efriedma, bjope Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D51169 llvm-svn: 341651
* [IndVars] Set Changed when we delete dead instructions. PR38855Max Kazantsev2018-09-071-1/+1
| | | | | | | | | | | IndVars does not set `Changed` flag when it eliminates dead instructions. As result, it may make IR modifications and report that it has done nothing. It leads to inconsistent preserved analyzes results. Differential Revision: https://reviews.llvm.org/D51770 Reviewed By: skatkov llvm-svn: 341633
* [LoopInterchange] Cleanup unused variables.Florian Hahn2018-09-061-8/+2
| | | | llvm-svn: 341537
* [LoopInterchange] Move preheader creation to transform stage and simplify.Florian Hahn2018-09-061-25/+18
| | | | | | | | | | | | | | | | | | | There is no need to create preheaders in the analysis stage, we only need them when adjusting the branches. Also, the only cases we need to create our own preheaders is when they have more than 1 predecessors or PHI nodes (even with only 1 predecessor, we could have an LCSSA phi node). I have simplified the conditions and added some assertions to be sure. Because we know the inner and outer loop need to be tightly nested, it is sufficient to check if the inner loop preheader is the outer loop header to check if we need to create a new preheader. Reviewers: efriedma, mcrosier, karthikthecool Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D51703 llvm-svn: 341533
* Revert "[IndVars] Turn isValidRewrite into an assertion" because it seems wrongMax Kazantsev2018-09-061-8/+9
| | | | llvm-svn: 341517
* [IndVars] Turn isValidRewrite into an assertionMax Kazantsev2018-09-061-9/+8
| | | | | | | | | | | | | | | Function rewriteLoopExitValues contains a check on isValidRewrite which is needed to make sure that SCEV does not convert the pattern `gep Base, (&p[n] - &p[0])` into `gep &p[n], Base - &p[0]`. This problem has been fixed in SCEV long ago, so this check is just obsolete. This patch converts it into an assertion to make sure that the SCEV will not mess up this case in the future. Differential Revision: https://reviews.llvm.org/D51582 Reviewed By: atrick llvm-svn: 341516
* Revert "Revert r341269: [Constant Hoisting] Hoisting Constant GEP Expressions"Zhaoshi Zheng2018-09-041-37/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Reland r341269. Use std::stable_sort when sorting constant condidates. Reverting commit, r341365: Revert r341269: [Constant Hoisting] Hoisting Constant GEP Expressions One of the tests is failing 50% of the time when expensive checks are enabled. Not sure how deep the problem is so just reverting while the author can investigate so that the bots stop repeatedly failing and blaming things incorrectly. Will respond with details on the original commit. Original commit, r341269: [Constant Hoisting] Hoisting Constant GEP Expressions Leverage existing logic in constant hoisting pass to transform constant GEP expressions sharing the same base global variable. Multi-dimensional GEPs are rewritten into single-dimensional GEPs. https://reviews.llvm.org/D51396 Differential Revision: https://reviews.llvm.org/D51654 llvm-svn: 341417
* [SimpleLoopUnswitch] remove a chain of dead blocks at onceFedor Sergeev2018-09-041-19/+19
| | | | | | | | | | | | | | | | | | | | | | Recent change to deleteDeadBlocksFromLoop was not enough to fix all the problems related to dead blocks after nontrivial unswitching of switches. We need to delete all the dead blocks that were created during unswitching, otherwise we will keep having problems with phi's or dead blocks. This change removes all the dead blocks that are reachable from the loop, not trying to track whether these blocks are newly created by unswitching or not. While not completely correct, we are unlikely to get loose but reachable dead blocks that do not belong to our loop nest. It does fix all the failures currently known, in particular PR38778. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D51519 llvm-svn: 341398
* Revert r341269: [Constant Hoisting] Hoisting Constant GEP ExpressionsChandler Carruth2018-09-041-136/+36
| | | | | | | | | | One of the tests is failing 50% of the time when expensive checks are enabled. Not sure how deep the problem is so just reverting while the author can investigate so that the bots stop repeatedly failing and blaming things incorrectly. Will respond with details on the original commit. llvm-svn: 341365
* [NFC] Add assert to detect LCSSA breaches earlyMax Kazantsev2018-09-041-0/+10
| | | | llvm-svn: 341347
* [IndVars] Fix usage of SCEVExpander to not mess with SCEVConstant. PR38674Max Kazantsev2018-09-041-18/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the function `expandSCEVIfNeeded` which behaves not as it was intended. This function tries to make a lookup for exact existing expansion and only goes to normal expansion via `expandCodeFor` if this lookup hasn't found anything. As a result of this, if some instruction above the loop has a `SCEVConstant` SCEV, this logic will return this instruction when asked for this `SCEVConstant` rather than return a constant value. This is both non-profitable and in some cases leads to breach of LCSSA form (as in PR38674). Whether or not it is possible to break LCSSA with this algorithm and with some non-constant SCEVs is still in question, this is still being investigated. I wasn't able to construct such a test so far, so maybe this situation is impossible. If it is, it will go as a separate fix. Rather than do it, it is always correct to just invoke `expandCodeFor` unconditionally: it behaves smarter about insertion points, and as side effect of this it will choose a constant value for SCEVConstants. For other SCEVs it may end up finding a better insertion point. So it should not be worse in any case. NOTE: So far the only known case for which this transform may break LCSSA is mapping of SCEVConstant to an instruction. However there is a suspicion that the entire algorithm can compromise LCSSA form for other cases as well (yet not proved). Differential Revision: https://reviews.llvm.org/D51286 Reviewed By: etherzhhb llvm-svn: 341345
OpenPOWER on IntegriCloud