mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +01:00
a3bce35a07
information. This allows arbitrary code involving DW_OP_plus_uconst and DW_OP_deref. The scheme allows for easy extention to include, any, or all of the DW_OP_ opcodes. I thought about just exposing all of them, but, wasn't sure if people wanted the dwarf opcodes exposed in the api. Is that a layering violation? With this scheme, the entire existing block scheme used by llvm-gcc can be switched over to the new scheme. I think that would be cleaner, as then the compiler specific bits are not present in llvm proper. Before the old code can be yanked however, similar code in clang would have to be removed. Next up, more testing. llvm-svn: 83120 |
||
|---|---|---|
| .. | ||
| 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 | ||
| InstCount.cpp | ||
| Interval.cpp | ||
| IntervalPartition.cpp | ||
| IVUsers.cpp | ||
| LibCallAliasAnalysis.cpp | ||
| LibCallSemantics.cpp | ||
| LiveValues.cpp | ||
| LoopDependenceAnalysis.cpp | ||
| LoopInfo.cpp | ||
| LoopPass.cpp | ||
| LoopVR.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.
//===---------------------------------------------------------------------===//