Martijn
2009-Nov-17 11:25 UTC
[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
Devang Patel
2009-Nov-17 18:35 UTC
[LLVMdev] llvm-gcc: missing dbg.declare/dbg.stoppoint at optimization level > O0
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
Martijn
2009-Nov-18 08:50 UTC
[LLVMdev] llvm-gcc: missing dbg.declare/dbg.stoppoint at optimization level > O0
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
Reasonably Related Threads
- [LLVMdev] llvm-gcc: missing dbg.declare/dbg.stoppoint at optimization level > O0
- [LLVMdev] llvm-gcc: missing dbg.declare/dbg.stoppoint at optimization level > O0
- [LLVMdev] llvm-gcc: missing dbg.declare/dbg.stoppoint at optimization level > O0
- [LLVMdev] debug stoppoints and control flow
- [LLVMdev] debug stoppoint nodes with -fast option