mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-26 13:36:28 +00:00
603a11de4e
identifying the malloc as a non-array malloc. This broke GlobalOpt's optimization of stores of mallocs to global variables. The fix is to classify malloc's into 3 categories: 1. non-array mallocs 2. array mallocs whose array size can be determined 3. mallocs that cannot be determined to be of type 1 or 2 and cannot be optimized getMallocArraySize() returns NULL for category 3, and all users of this function must avoid their malloc optimization if this function returns NULL. Eventually, currently unexpected codegen for computing the malloc's size argument will be supported in isArrayMalloc() and getMallocArraySize(), extending malloc optimizations to those examples. llvm-svn: 84199 |
||
---|---|---|
.. | ||
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 | ||
InlineCost.cpp | ||
InstCount.cpp | ||
Interval.cpp | ||
IntervalPartition.cpp | ||
IVUsers.cpp | ||
LibCallAliasAnalysis.cpp | ||
LibCallSemantics.cpp | ||
LiveValues.cpp | ||
LoopDependenceAnalysis.cpp | ||
LoopInfo.cpp | ||
LoopPass.cpp | ||
Makefile | ||
MallocHelper.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. //===---------------------------------------------------------------------===//