forked from OSchip/llvm-project
cf9138307d
use plain SCEVUnknowns with ConstantExpr::getSizeOf and ConstantExpr::getOffsetOf constants. This eliminates a bunch of special-case code. Also add code for pattern-matching these expressions, for clients that want to recognize them. Move ScalarEvolution's logic for expanding array and vector sizeof expressions into an element count times the element size, to expose the multiplication to subsequent folding, into the regular constant folder. llvm-svn: 94737 |
||
|---|---|---|
| .. | ||
| IPA | ||
| AliasAnalysis.cpp | ||
| AliasAnalysisCounter.cpp | ||
| AliasAnalysisEvaluator.cpp | ||
| AliasDebugger.cpp | ||
| AliasSetTracker.cpp | ||
| Analysis.cpp | ||
| BasicAliasAnalysis.cpp | ||
| CFGPrinter.cpp | ||
| CMakeLists.txt | ||
| CaptureTracking.cpp | ||
| ConstantFolding.cpp | ||
| DbgInfoPrinter.cpp | ||
| DebugInfo.cpp | ||
| DomPrinter.cpp | ||
| IVUsers.cpp | ||
| InlineCost.cpp | ||
| InstCount.cpp | ||
| InstructionSimplify.cpp | ||
| Interval.cpp | ||
| IntervalPartition.cpp | ||
| LazyValueInfo.cpp | ||
| LibCallAliasAnalysis.cpp | ||
| LibCallSemantics.cpp | ||
| LiveValues.cpp | ||
| LoopDependenceAnalysis.cpp | ||
| LoopInfo.cpp | ||
| LoopPass.cpp | ||
| Makefile | ||
| MemoryBuiltins.cpp | ||
| MemoryDependenceAnalysis.cpp | ||
| PHITransAddr.cpp | ||
| PointerTracking.cpp | ||
| PostDominators.cpp | ||
| ProfileEstimatorPass.cpp | ||
| ProfileInfo.cpp | ||
| ProfileInfoLoader.cpp | ||
| ProfileInfoLoaderPass.cpp | ||
| ProfileVerifierPass.cpp | ||
| README.txt | ||
| ScalarEvolution.cpp | ||
| ScalarEvolutionAliasAnalysis.cpp | ||
| ScalarEvolutionExpander.cpp | ||
| SparsePropagation.cpp | ||
| Trace.cpp | ||
| ValueTracking.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.
//===---------------------------------------------------------------------===//