llvm-mirror/lib/Analysis
Dan Gohman 1cc421b590 Fix SCEVExpander's existing PHI reuse checking to recognize the
case where there are loop-invariant instructions somehow left
inside the loop, and in a position where they won't dominate
the IV increment position.

llvm-svn: 96448
2010-02-17 02:39:31 +00:00
..
IPA
AliasAnalysis.cpp
AliasAnalysisCounter.cpp
AliasAnalysisEvaluator.cpp
AliasDebugger.cpp
AliasSetTracker.cpp
Analysis.cpp
BasicAliasAnalysis.cpp
CaptureTracking.cpp
CFGPrinter.cpp
CMakeLists.txt
ConstantFolding.cpp
DbgInfoPrinter.cpp
DebugInfo.cpp
DomPrinter.cpp
InlineCost.cpp
InstCount.cpp
InstructionSimplify.cpp
Interval.cpp
IntervalPartition.cpp
IVUsers.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

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.

//===---------------------------------------------------------------------===//