mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-21 03:53:04 +02:00
90f7376682
analyses when we're about to break apart an SCC. We can't wait until after breaking apart the SCC to invalidate things: 1) Which SCC do we then invalidate? All of them? 2) Even if we invalidate all of them, a newly created SCC may not have a proxy that will convey the invalidation to functions! Previously we only invalidated one of the SCCs and too late. This led to stale analyses remaining in the cache. And because the caching strategy actually works, they would get used and chaos would ensue. Doing invalidation early is somewhat pessimizing though if we *know* that the SCC structure won't change. So it turns out that the design to make the mutation API force the caller to know the *kind* of mutation in advance was indeed 100% correct and we didn't do enough of it. So this change also splits two cases of switching a call edge to a ref edge into two separate APIs so that callers can clearly test for this and take the easy path without invalidating when appropriate. This is particularly important in this case as we expect most inlines to be between functions in separate SCCs and so the common case is that we don't have to so aggressively invalidate analyses. The LCG API change in turn needed some basic cleanups and better testing in its unittest. No interesting functionality changed there other than more coverage of the returned sequence of SCCs. While this seems like an obvious improvement over the current state, I'd like to revisit the core concept of invalidating within the CG-update layer at all. I'm wondering if we would be better served forcing the callers to handle the invalidation beforehand in the cases that they can handle it. An interesting example is when we want to teach the inliner to *update and preserve* analyses. But we can cross that bridge when we get there. With this patch, the new pass manager an build all of the LLVM test suite at -O3 and everything passes. =D I haven't bootstrapped yet and I'm sure there are still plenty of bugs, but this gives a nice baseline so I'm going to increasingly focus on fleshing out the missing functionality, especially the bits that are just turned off right now in order to let us establish this baseline. llvm-svn: 290664 |
||
|---|---|---|
| .. | ||
| AliasAnalysis.cpp | ||
| AliasAnalysisEvaluator.cpp | ||
| AliasAnalysisSummary.cpp | ||
| AliasAnalysisSummary.h | ||
| AliasSetTracker.cpp | ||
| Analysis.cpp | ||
| AssumptionCache.cpp | ||
| BasicAliasAnalysis.cpp | ||
| BlockFrequencyInfo.cpp | ||
| BlockFrequencyInfoImpl.cpp | ||
| BranchProbabilityInfo.cpp | ||
| CallGraph.cpp | ||
| CallGraphSCCPass.cpp | ||
| CallPrinter.cpp | ||
| CaptureTracking.cpp | ||
| CFG.cpp | ||
| CFGPrinter.cpp | ||
| CFLAndersAliasAnalysis.cpp | ||
| CFLGraph.h | ||
| CFLSteensAliasAnalysis.cpp | ||
| CGSCCPassManager.cpp | ||
| CMakeLists.txt | ||
| CodeMetrics.cpp | ||
| ConstantFolding.cpp | ||
| CostModel.cpp | ||
| Delinearization.cpp | ||
| DemandedBits.cpp | ||
| DependenceAnalysis.cpp | ||
| DivergenceAnalysis.cpp | ||
| DominanceFrontier.cpp | ||
| DomPrinter.cpp | ||
| EHPersonalities.cpp | ||
| GlobalsModRef.cpp | ||
| IndirectCallPromotionAnalysis.cpp | ||
| InlineCost.cpp | ||
| InstCount.cpp | ||
| InstructionSimplify.cpp | ||
| Interval.cpp | ||
| IntervalPartition.cpp | ||
| IteratedDominanceFrontier.cpp | ||
| IVUsers.cpp | ||
| LazyBlockFrequencyInfo.cpp | ||
| LazyBranchProbabilityInfo.cpp | ||
| LazyCallGraph.cpp | ||
| LazyValueInfo.cpp | ||
| Lint.cpp | ||
| LLVMBuild.txt | ||
| 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 | ||
| OptimizationDiagnosticInfo.cpp | ||
| OrderedBasicBlock.cpp | ||
| PHITransAddr.cpp | ||
| PostDominators.cpp | ||
| ProfileSummaryInfo.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 | ||
| TypeMetadataUtils.cpp | ||
| ValueTracking.cpp | ||
| VectorUtils.cpp | ||
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))
//===---------------------------------------------------------------------===//