llvm dev - Nov 2009 - [LLVMdev] llvm-gcc: missing dbg.declare/dbg.stoppoint at optimization level > O0

Hi Devang,
>> I use llvm and llvm-gcc as a C-to-C transformation tool using a
>> modified version of the c backend, and rely on llvm debug instructions
>> to link back to the original source code.
>>
>> Does anyone know how to get detailed line number and variable debug
>> information at optimization levels beyond O0?
>>
>> Currently, I extract this debug information by compiling with -g.
>> This works fine with "llvm-gcc -g -O0 --emit-llvm", i.e. no
>> optimizations, but when I enable optimizations, e.g. "llvm-gcc -g
-O2
>> --emit-llvm",
>> most of the dbg.stoppoint and dbg.declare instructions dissapear.
>>
>> I tried to enable at least debug.declare instructions by removing the
>> "if(optimize) return" statement in gcc/llvm-debug.cpp,
>> DebugInfo::EmitDeclare(), but I still do not get any dbg.declare
>> instructions.
>
> This will enable dbg.declare, but they'll be removed by mem2reg pass
> immediately.
>
>> Is there a way to keep all debug information with optimizations
>> enabled in llvm-gcc?
>> If I have to disable some specific optimizations to keep the debug
>> info correct that is fine.
>
> Without mem2reg pass, you're unlikely to get much optimization done on
your IR.
Clear, thanks! I presume the mem2reg pass is also essential in the
CLang frontend, so CLang is not an alternative to llvm-gcc to keep
more debug information?

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?
>
> 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!
The llvm.dbg.value proposal looks very interesting. We would like to
contribute if possible. I estimate we do not have sufficient llvm
experience to contribute ourselves, but may take up a part of the work
using a contractor. Can you identify a clear part for which we could
hire a contractor?

Martijn

Hi Martijn,

On Tue, Nov 17, 2009 at 3:25 AM, Martijn <martijn at martijnrutten.com>
wrote:
>>
>> Without mem2reg pass, you're unlikely to get much optimization done
on your IR.
>
> Clear, thanks! I presume the mem2reg pass is also essential in the
> CLang frontend, so CLang is not an alternative to llvm-gcc to keep
> more debug information?
Yes.
> 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.
>>
>> 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!
>
> The llvm.dbg.value proposal looks very interesting. We would like to
> contribute if possible. I estimate we do not have sufficient llvm
> experience to contribute ourselves, but may take up a part of the work
> using a contractor. Can you identify a clear part for which we could
> hire a contractor?
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.

-
Devang

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