Yuri
2014-Feb-02 09:11 UTC
[LLVMdev] Why variables get "optimized away" after the last use in unoptimized code?
I am seeing this with llvm generated code, and before also saw this with gcc generated code. In unoptimized code, debugger would say something like this when the variable isn't used any more, but is still in scope: (gdb) p this $11 = <optimized out> Looking at the debug records, I don't see what is wrong, for example: call void @llvm.dbg.declare(metadata !{%struct.Object* %1}, metadata !73), !dbg !74 !73 = metadata !{i32 786689, metadata !63, metadata !"this", metadata !68, i32 33554949, metadata !12, i32 0, i32 0} ; [ DW_TAG_arg_variable ] [this] [line 517] !63 is DW_TAG_subprogram scope. 'this' should exist through this subprogram, and never disappear. But it becomes "optimized away" after the last explicit use. Same is true with any other variable. Doesn't this mean that llvm generates wrong DWARF info? I don't think that debugger should ever say <optimized out> in unoptimized code. Yuri
David Chisnall
2014-Feb-02 09:48 UTC
[LLVMdev] Why variables get "optimized away" after the last use in unoptimized code?
On 2 Feb 2014, at 09:11, Yuri <yuri at rawbw.com> wrote:> I am seeing this with llvm generated code, and before also saw this with gcc generated code. > In unoptimized code, debugger would say something like this when the variable isn't used any more, but is still in scope: > (gdb) p this > $11 = <optimized out> > > Looking at the debug records, I don't see what is wrong, for example: > call void @llvm.dbg.declare(metadata !{%struct.Object* %1}, metadata !73), !dbg !74 > !73 = metadata !{i32 786689, metadata !63, metadata !"this", metadata !68, i32 33554949, metadata !12, i32 0, i32 0} ; [ DW_TAG_arg_variable ] [this] [line 517] > !63 is DW_TAG_subprogram scope. > > 'this' should exist through this subprogram, and never disappear. But it becomes "optimized away" after the last explicit use. Same is true with any other variable. > Doesn't this mean that llvm generates wrong DWARF info? > I don't think that debugger should ever say <optimized out> in unoptimized code.In most calling conventions, this is a callee-save register. After its last use, the register allocator may reuse that register. On x86 and ARM, the register that contains this is also (usually) the register used for return values, so it definitely will reuse it at some point before return in any method that returns a value. The only way to avoid this would be to spill it to the stack and have the debug information point to the spill slot. If there are any function / method calls within the method, this will be spilled and so there will be a copy of it on the stack. It might be quite nice for the debug info to prefer to reference this one, but it's not possible for most other parameters. David
Yuri
2014-Feb-02 09:57 UTC
[LLVMdev] Why variables get "optimized away" after the last use in unoptimized code?
On 02/02/2014 01:48, David Chisnall wrote:> In most calling conventions, this is a callee-save register. After its last use, the register allocator may reuse that register. On x86 and ARM, the register that contains this is also (usually) the register used forBut the rule "after the last use, the register allocator may reuse it" is also introduced by llvm, since register allocator is also llvm. So this means that the rule "preserve any values while in scope as much as possible" is probably a better one for debugging. Yuri
Yuri
2014-Feb-02 20:07 UTC
[LLVMdev] Why variables get "optimized away" after the last use in unoptimized code?
On 02/02/2014 01:11, Yuri wrote:> 'this' should exist through this subprogram, and never disappear. But > it becomes "optimized away" after the last explicit use. Same is true > with any other variable. > Doesn't this mean that llvm generates wrong DWARF info? > I don't think that debugger should ever say <optimized out> in > unoptimized code.I submitted the issue with my proposal: http://llvm.org/bugs/show_bug.cgi?id=18697 Yuri
Apparently Analagous Threads
- [LLVMdev] Why variables get "optimized away" after the last use in unoptimized code?
- [LLVMdev] Why UnreachableInst instruction is required when the last call has NoReturn flag?
- [LLVMdev] Why code doesn't speed up much with optimization level increase?
- [LLVMdev] --enable-shared doesn't build shared library any more
- [LLVMdev] [PATCH] with no response: Bug 13163 - BlockAddress instruction with use from the global context is damaged during module link