mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-26 23:29:22 +00:00
e4ba75f43e
TargetTransformInfo rather than TargetLowering, removing one of the primary instances of the layering violation of Transforms depending directly on Target. This is a really big deal because LSR used to be a "special" pass that could only be tested fully using llc and by looking at the full output of it. It also couldn't run with any other loop passes because it had to be created by the backend. No longer is this true. LSR is now just a normal pass and we should probably lift the creation of LSR out of lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done this, or updated all of the tests to use opt and a triple, because I suspect someone more familiar with LSR would do a better job. This change should be essentially without functional impact for normal compilations, and only change behvaior of targetless compilations. The conversion required changing all of the LSR code to refer to the TTI interfaces, which fortunately are very similar to TargetLowering's interfaces. However, it also allowed us to *always* expect to have some implementation around. I've pushed that simplification through the pass, and leveraged it to simplify code somewhat. It required some test updates for one of two things: either we used to skip some checks altogether but now we get the default "no" answer for them, or we used to have no information about the target and now we do have some. I've also started the process of removing AddrMode, as the TTI interface doesn't use it any longer. In some cases this simplifies code, and in others it adds some complexity, but I think it's not a bad tradeoff even there. Subsequent patches will try to clean this up even further and use other (more appropriate) abstractions. Yet again, almost all of the formatting changes brought to you by clang-format. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171735 91177308-0d34-0410-b5e6-96231b3b80d8 |
||
|---|---|---|
| .. | ||
| IPA | ||
| AliasAnalysis.cpp | ||
| AliasAnalysisCounter.cpp | ||
| AliasAnalysisEvaluator.cpp | ||
| AliasDebugger.cpp | ||
| AliasSetTracker.cpp | ||
| Analysis.cpp | ||
| BasicAliasAnalysis.cpp | ||
| BlockFrequencyInfo.cpp | ||
| BranchProbabilityInfo.cpp | ||
| CaptureTracking.cpp | ||
| CFGPrinter.cpp | ||
| CMakeLists.txt | ||
| CodeMetrics.cpp | ||
| ConstantFolding.cpp | ||
| CostModel.cpp | ||
| DbgInfoPrinter.cpp | ||
| DependenceAnalysis.cpp | ||
| DominanceFrontier.cpp | ||
| DomPrinter.cpp | ||
| InlineCost.cpp | ||
| InstCount.cpp | ||
| InstructionSimplify.cpp | ||
| Interval.cpp | ||
| IntervalPartition.cpp | ||
| IVUsers.cpp | ||
| LazyValueInfo.cpp | ||
| LibCallAliasAnalysis.cpp | ||
| LibCallSemantics.cpp | ||
| Lint.cpp | ||
| LLVMBuild.txt | ||
| Loads.cpp | ||
| LoopInfo.cpp | ||
| LoopPass.cpp | ||
| Makefile | ||
| MemDepPrinter.cpp | ||
| MemoryBuiltins.cpp | ||
| MemoryDependenceAnalysis.cpp | ||
| ModuleDebugInfoPrinter.cpp | ||
| NoAliasAnalysis.cpp | ||
| PathNumbering.cpp | ||
| PathProfileInfo.cpp | ||
| PathProfileVerifier.cpp | ||
| PHITransAddr.cpp | ||
| PostDominators.cpp | ||
| ProfileDataLoader.cpp | ||
| ProfileDataLoaderPass.cpp | ||
| ProfileEstimatorPass.cpp | ||
| ProfileInfo.cpp | ||
| ProfileInfoLoader.cpp | ||
| ProfileInfoLoaderPass.cpp | ||
| ProfileVerifierPass.cpp | ||
| PtrUseVisitor.cpp | ||
| README.txt | ||
| RegionInfo.cpp | ||
| RegionPass.cpp | ||
| RegionPrinter.cpp | ||
| ScalarEvolution.cpp | ||
| ScalarEvolutionAliasAnalysis.cpp | ||
| ScalarEvolutionExpander.cpp | ||
| ScalarEvolutionNormalization.cpp | ||
| SparsePropagation.cpp | ||
| TargetTransformInfo.cpp | ||
| Trace.cpp | ||
| TypeBasedAliasAnalysis.cpp | ||
| ValueTracking.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))
//===---------------------------------------------------------------------===//