llvm-6502

mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-11-05 13:09:10 +00:00

History

Mike Stump 3e4c9bdb67 Add a way for a frontend to generate more complex dwarf location 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83120 91177308-0d34-0410-b5e6-96231b3b80d8		2009-09-30 00:08:22 +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	Add a way for a frontend to generate more complex dwarf location	2009-09-30 00:08:22 +00:00
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

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.

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