mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-23 12:08:25 +00:00
198fbdadcf
same object to be a non-capture; Duncan pointed out a way that such a comparison could be a capture. Make the rule that considers a comparison against null more specific, and only consider noalias return values compared against null. This still supports test/Transforms/GVN/nonescaping-malloc.ll, and is not susceptible to the problem Duncan pointed out with noalias arguments. llvm-svn: 89468 |
||
---|---|---|
.. | ||
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 | ||
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. //===---------------------------------------------------------------------===//