[LLVMdev] llvm-gcc: missing dbg.declare/dbg.stoppoint at optimization level > O0
Martijn
martijn at martijnrutten.com
Wed Nov 18 00:50:28 PST 2009
Hi Devang,
>> For the dbg.stoppoints: many of the stoppoint instructions dissapear
>> at higher optimization levels. We need these to link back instructions
>> to original C statements. I guess this is not related to the mem2reg
>> pass. Is there a way to at least keep the stoppoint instructions?
>
> Good news. In mainline svn sources, llvm, llvm-gcc and clang, are not
> using dbg.stoppoints. Now location info (line, column and scope) is
> attached directly with llvm instructions. This way, the info is more
> likely to survive through optimization passes. The optimizer may lose
> info when it replaces one set of instructions with another set,
> however that is now easier to track and fix. For example, inliner is
> now appropriately coping info when it copies function body. This is a
> recent development.
That is great news, somehow I overlooked this on the mailing list, my
bad. I will look into this asap.
>>>
>>> We're working on the required support to enable variable debug info at -O1+.
>>> http://nondot.org/~sabre/LLVMNotes/DebugInfoVariableInfo.txt
>>> Let us know if you'd like to contribute in this area!
>>
> This work can be largely divided into 3 phases.
>
> 1) Emit and preserve llvm.dbg.var intrinsic through target independent
> optimization passes. This requires experience dealing with llvm
> transformation passes. Victor Hernandez has started working on this
> phase.
> 2) Lower llvm.dbg.var and preserve variable info through code
> generation passes. This requires codegen familiarity.
> 3) Emit appropriate DWARF entries based on the variable info that
> survives through optimization and codegen passes. DWARF knowledge is
> useful here.
Our interest is only in the target independent part 1) since we use
something similar to the C backend, i.e. no codegen/dwarf.
If this is already work in progress, can we help out in testing
preliminary work?
Martijn
More information about the llvm-dev
mailing list