aboutsummaryrefslogtreecommitdiffstats
path: root/lib/CodeGen/MachineModuleInfo.cpp
diff options
context:
space:
mode:
authorMike Stump <mrs@apple.com>2009-09-30 00:08:22 +0000
committerMike Stump <mrs@apple.com>2009-09-30 00:08:22 +0000
commitb22cd0ff4c6c3ba4a39b8b11afb21ddf40e79f74 (patch)
tree303dcada7defc4cf42447ffa6e3f4d0a32522760 /lib/CodeGen/MachineModuleInfo.cpp
parent278c839fdb36f39a25935fd83e12144b374d4e75 (diff)
downloadexternal_llvm-b22cd0ff4c6c3ba4a39b8b11afb21ddf40e79f74.tar.gz
external_llvm-b22cd0ff4c6c3ba4a39b8b11afb21ddf40e79f74.tar.bz2
external_llvm-b22cd0ff4c6c3ba4a39b8b11afb21ddf40e79f74.zip
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
Diffstat (limited to 'lib/CodeGen/MachineModuleInfo.cpp')
0 files changed, 0 insertions, 0 deletions