summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [Reassociate] swap binop operands to increase factoring potentialSanjay Patel2018-09-021-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a pair of binops feeding another pair of binops, rearrange the operands so the matching pair are together because that allows easy factorization folds to happen in instcombine: ((X << S) & Y) & (Z << S) --> ((X << S) & (Z << S)) & Y (reassociation) --> ((X & Z) << S) & Y (factorize shift from 'and' ops optimization) This is part of solving PR37098: https://bugs.llvm.org/show_bug.cgi?id=37098 Note that there's an instcombine version of this patch attached there, but we're trying to make instcombine have less responsibility to improve compile-time efficiency. For reasons I still don't completely understand, reassociate does this kind of transform sometimes, but misses everything in my motivating cases. This patch on its own is gluing an independent cleanup chunk to the end of the existing RewriteExprTree() loop. We can build on it and do something stronger to better order the full expression tree like D40049. That might be an alternative to the proposal to add a separate reassociation pass like D41574. Differential Revision: https://reviews.llvm.org/D45842 llvm-svn: 341288
* [Constant Hoisting] Hoisting Constant GEP ExpressionsZhaoshi Zheng2018-09-011-36/+136
| | | | | | | | | | 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. Differential Revision: https://reviews.llvm.org/D51396 llvm-svn: 341269
* [SROA] Fix alignment for uses of PHI nodes.Eli Friedman2018-08-301-0/+42
| | | | | | | | | | | | Splitting an alloca can decrease the alignment of GEPs into the partition. Normally, rewriting accounts for this, but the code was missing for uses of PHI nodes and select instructions. Fixes https://bugs.llvm.org/show_bug.cgi?id=38707 . Differential Revision: https://reviews.llvm.org/D51335 llvm-svn: 341094
* [NFC] Rename the DivergenceAnalysis to LegacyDivergenceAnalysisNicolai Haehnle2018-08-302-10/+10
| | | | | | | | | | | | | | | | | | | | Summary: This is patch 1 of the new DivergenceAnalysis (https://reviews.llvm.org/D50433). The purpose of this patch is to free up the name DivergenceAnalysis for the new generic implementation. The generic implementation class will be shared by specialized divergence analysis classes. Patch by: Simon Moll Reviewed By: nhaehnle Subscribers: jvesely, jholewinski, arsenm, nhaehnle, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50434 Change-Id: Ie8146b11be2c50d5312f30e11c7a3036a15b48cb llvm-svn: 341071
* Re-enable "[NFC] Unify guards detection"Max Kazantsev2018-08-305-15/+12
| | | | | | | | | | rL340921 has been reverted by rL340923 due to linkage dependency from Transform/Utils to Analysis which is not allowed. In this patch this has been fixed, a new utility function moved to Analysis. Differential Revision: https://reviews.llvm.org/D51152 llvm-svn: 341014
* Add a todo and tests to Address a review commnt from D50925 [NFC]Philip Reames2018-08-291-1/+3
| | | | llvm-svn: 340978
* [LICM] Hoist stores of invariant values to invariant addresses out of loopsPhilip Reames2018-08-291-3/+23
| | | | | | | | | | | | Teach LICM to hoist stores out of loops when the store writes to a location otherwise unused in the loop, writes a value which is invariant, and is guaranteed to execute if the loop is entered. Worth noting is that this transformation is partially overlapping with the existing promotion transformation. Reasons this is worthwhile anyway include: * For multi-exit loops, this doesn't require duplication of the store. * It kicks in for case where we can't prove we exit through a normal exit (i.e. we may throw), but can prove the store executes before that possible side exit. Differential Revision: https://reviews.llvm.org/D50925 llvm-svn: 340974
* [SimpleLoopUnswitch] After unswitch delete dead blocks in parent loopsFedor Sergeev2018-08-291-2/+10
| | | | | | | | | | | | | | | | | | | | Summary: Assert from PR38737 happens on the dead block inside the parent loop after unswitching nontrivial switch in the inner loop. deleteDeadBlocksFromLoop now takes extra care to detect/remove dead blocks in all the parent loops in addition to the blocks from original loop being unswitched. Reviewers: asbirlea, chandlerc Reviewed By: asbirlea Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51415 llvm-svn: 340955
* Revert r340921 "[NFC] Unify guards detection"Hans Wennborg2018-08-295-10/+15
| | | | | | | | | | | | | | | | | | This broke the build, see e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv8-lnt/builds/4626/ http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/18647/ http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/5856/ http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/22800/ > We have multiple places in code where we try to identify whether or not > some instruction is a guard. This patch factors out this logic into a separate > utility function which works uniformly in all places. > > Differential Revision: https://reviews.llvm.org/D51152 > Reviewed By: fedor.sergeev llvm-svn: 340923
* [NFC] Unify guards detectionMax Kazantsev2018-08-295-15/+10
| | | | | | | | | | | We have multiple places in code where we try to identify whether or not some instruction is a guard. This patch factors out this logic into a separate utility function which works uniformly in all places. Differential Revision: https://reviews.llvm.org/D51152 Reviewed By: fedor.sergeev llvm-svn: 340921
OpenPOWER on IntegriCloud