forked from OSchip/llvm-project
b7b8052982
Summary: ...loop after the last iteration. This is really hard to do correctly. The core problem is that we need to model liveness through the induction PHIs from iteration to iteration in order to get the correct results, and we need to correctly de-duplicate the common subgraphs of instructions feeding some subset of the induction PHIs. All of this can be driven either from a side effect at some iteration or from the loop values used after the loop finishes. This patch implements this by storing the forward-propagating analysis of each instruction in a cache to recall whether it was free and whether it has become live and thus counted toward the total unroll cost. Then, at each sink for a value in the loop, we recursively walk back through every value that feeds the sink, including looping back through the iterations as needed, until we have marked the entire input graph as live. Because we cache this, we never visit instructions more than twice -- once when we analyze them and put them into the cache, and once when we count their cost towards the unrolled loop. Also, because the cache is only two bits and because we are dealing with relatively small iteration counts, we can store all of this very densely in memory to avoid this from becoming an excessively slow analysis. The code here is still pretty gross. I would appreciate suggestions about better ways to factor or split this up, I've stared too long at the algorithmic side to really have a good sense of what the design should probably look at. Also, it might seem like we should do all of this bottom-up, but I think that is a red herring. Specifically, the simplification power is *much* greater working top-down. We can forward propagate very effectively, even across strange and interesting recurrances around the backedge. Because we use data to propagate, this doesn't cause a state space explosion. Doing this level of constant folding, etc, would be very expensive to do bottom-up because it wouldn't be until the last moment that you could collapse everything. The current solution is essentially a top-down simplification with a bottom-up cost accounting which seems to get the best of both worlds. It makes the simplification incremental and powerful while leaving everything dead until we *know* it is needed. Finally, a core property of this approach is its *monotonicity*. At all times, the current UnrolledCost is a conservatively low estimate. This ensures that we will never early-exit from the analysis due to exceeding a threshold when if we had continued, the cost would have gone back below the threshold. These kinds of bugs can cause incredibly hard to track down random changes to behavior. We could use a techinque similar (but much simpler) within the inliner as well to avoid considering speculated code in the inline cost. Reviewers: chandlerc Subscribers: sanjoy, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D11758 llvm-svn: 269388 |
||
|---|---|---|
| .. | ||
| AliasAnalysis.cpp | ||
| AliasAnalysisEvaluator.cpp | ||
| AliasSetTracker.cpp | ||
| Analysis.cpp | ||
| AssumptionCache.cpp | ||
| BasicAliasAnalysis.cpp | ||
| BitSetUtils.cpp | ||
| BlockFrequencyInfo.cpp | ||
| BlockFrequencyInfoImpl.cpp | ||
| BranchProbabilityInfo.cpp | ||
| CFG.cpp | ||
| CFGPrinter.cpp | ||
| CFLAliasAnalysis.cpp | ||
| CGSCCPassManager.cpp | ||
| CMakeLists.txt | ||
| CallGraph.cpp | ||
| CallGraphSCCPass.cpp | ||
| CallPrinter.cpp | ||
| CaptureTracking.cpp | ||
| CodeMetrics.cpp | ||
| ConstantFolding.cpp | ||
| CostModel.cpp | ||
| Delinearization.cpp | ||
| DemandedBits.cpp | ||
| DependenceAnalysis.cpp | ||
| DivergenceAnalysis.cpp | ||
| DomPrinter.cpp | ||
| DominanceFrontier.cpp | ||
| EHPersonalities.cpp | ||
| GlobalsModRef.cpp | ||
| IVUsers.cpp | ||
| InlineCost.cpp | ||
| InstCount.cpp | ||
| InstructionSimplify.cpp | ||
| Interval.cpp | ||
| IntervalPartition.cpp | ||
| IteratedDominanceFrontier.cpp | ||
| LLVMBuild.txt | ||
| LazyCallGraph.cpp | ||
| LazyValueInfo.cpp | ||
| Lint.cpp | ||
| Loads.cpp | ||
| LoopAccessAnalysis.cpp | ||
| LoopInfo.cpp | ||
| LoopPass.cpp | ||
| LoopPassManager.cpp | ||
| LoopUnrollAnalyzer.cpp | ||
| MemDepPrinter.cpp | ||
| MemDerefPrinter.cpp | ||
| MemoryBuiltins.cpp | ||
| MemoryDependenceAnalysis.cpp | ||
| MemoryLocation.cpp | ||
| ModuleDebugInfoPrinter.cpp | ||
| ModuleSummaryAnalysis.cpp | ||
| ObjCARCAliasAnalysis.cpp | ||
| ObjCARCAnalysisUtils.cpp | ||
| ObjCARCInstKind.cpp | ||
| OrderedBasicBlock.cpp | ||
| PHITransAddr.cpp | ||
| PostDominators.cpp | ||
| PtrUseVisitor.cpp | ||
| README.txt | ||
| RegionInfo.cpp | ||
| RegionPass.cpp | ||
| RegionPrinter.cpp | ||
| ScalarEvolution.cpp | ||
| ScalarEvolutionAliasAnalysis.cpp | ||
| ScalarEvolutionExpander.cpp | ||
| ScalarEvolutionNormalization.cpp | ||
| ScopedNoAliasAA.cpp | ||
| SparsePropagation.cpp | ||
| StratifiedSets.h | ||
| TargetLibraryInfo.cpp | ||
| TargetTransformInfo.cpp | ||
| Trace.cpp | ||
| TypeBasedAliasAnalysis.cpp | ||
| ValueTracking.cpp | ||
| VectorUtils.cpp | ||
README.txt
Analysis Opportunities:
//===---------------------------------------------------------------------===//
In test/Transforms/LoopStrengthReduce/quadradic-exit-value.ll, the
ScalarEvolution expression for %r is this:
{1,+,3,+,2}<loop>
Outside the loop, this could be evaluated simply as (%n * %n), however
ScalarEvolution currently evaluates it as
(-2 + (2 * (trunc i65 (((zext i64 (-2 + %n) to i65) * (zext i64 (-1 + %n) to i65)) /u 2) to i64)) + (3 * %n))
In addition to being much more complicated, it involves i65 arithmetic,
which is very inefficient when expanded into code.
//===---------------------------------------------------------------------===//
In formatValue in test/CodeGen/X86/lsr-delayed-fold.ll,
ScalarEvolution is forming this expression:
((trunc i64 (-1 * %arg5) to i32) + (trunc i64 %arg5 to i32) + (-1 * (trunc i64 undef to i32)))
This could be folded to
(-1 * (trunc i64 undef to i32))
//===---------------------------------------------------------------------===//