[llvm-bugs] [Bug 40638] New: First DBG_VALUE for parameter is moved down after the end of the prologue (before DebugHandlerBase)
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Feb 7 00:17:56 PST 2019
https://bugs.llvm.org/show_bug.cgi?id=40638
Bug ID: 40638
Summary: First DBG_VALUE for parameter is moved down after the
end of the prologue (before DebugHandlerBase)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedbugs at nondot.org
Reporter: david.stenberg at ericsson.com
CC: jdevlieghere at apple.com, keith.walker at arm.com,
llvm-bugs at lists.llvm.org,
paul_robinson at playstation.sony.com
Spun out of PR40188.
When compiling the following example, lst.c:
int g1, g2;
void foo(int *p1) {
g1 = g2;
*p1 = 0;
}
using:
$ clang --target=i386-unknown-linux-gnu -g -O1 lst.c
we land in a situation where we have a DBG_VALUE for p1 at the start of the
function before register allocation:
# *** IR Dump Before Debug Variable Analysis ***:
# Machine code for function foo: NoPHIs, TracksLiveness
Frame Objects:
fi#-1: size=4, align=16, fixed, at location [SP+4]
0B bb.0.entry:
DBG_VALUE %fixed-stack.0, 0, !"p1", !DIExpression(), debug-location
!20; lst.c:3:15 line no:3
16B %0:gr32 = MOV32rm %fixed-stack.0, 1, $noreg, 0, $noreg :: (load 4
from %fixed-stack.0, align 16)
32B %1:gr32 = MOV32rm $noreg, 1, $noreg, @g2, $noreg, debug-location !21
:: (dereferenceable load 4 from @g2, !tbaa !22); lst.c:4:8
48B MOV32mr $noreg, 1, $noreg, @g1, $noreg, %1:gr32, debug-location !26
:: (store 4 into @g1, !tbaa !22); lst.c:4:6
64B MOV32mi %0:gr32, 1, $noreg, 0, $noreg, 0, debug-location !27 ::
(store 4 into %ir.p1, !tbaa !22); lst.c:5:7
80B RET 0, debug-location !28; lst.c:6:1
# End machine code for function foo.
********** COMPUTING LIVE DEBUG VARIABLES: foo **********
********** DEBUG VARIABLES **********
!"p1,3" [32B;96B):0 ind Loc0=%stack.4294967295
The lexical-scope trimming in LiveDebugVariables results in the value being
moved down after the first, DL-less instruction:
********** EMITTING LIVE DEBUG VARIABLES **********
!"p1,3" [32B;96B):0 ind Loc0=%stack.4294967295
[16B;96B):0 %bb.0-96B
********** EMITTING LIVE DEBUG LABELS **********
# *** IR Dump After Virtual Register Rewriter ***:
# Machine code for function foo: NoPHIs, TracksLiveness, NoVRegs
Frame Objects:
fi#-1: size=4, align=16, fixed, at location [SP+4]
0B bb.0.entry:
16B renamable $eax = MOV32rm %fixed-stack.0, 1, $noreg, 0, $noreg ::
(load 4 from %fixed-stack.0, align 16)
DBG_VALUE %fixed-stack.0, 0, !"p1", !DIExpression(), debug-location
!20; lst.c:3:15 line no:3
32B renamable $ecx = MOV32rm $noreg, 1, $noreg, @g2, $noreg,
debug-location !21 :: (dereferenceable load 4 from @g2, !tbaa !22); lst.c:4:8
48B MOV32mr $noreg, 1, $noreg, @g1, $noreg, killed renamable $ecx,
debug-location !26 :: (store 4 into @g1, !tbaa !22); lst.c:4:6
64B MOV32mi killed renamable $eax, 1, $noreg, 0, $noreg, 0,
debug-location !27 :: (store 4 into %ir.p1, !tbaa !22); lst.c:5:7
80B RET 0, debug-location !28; lst.c:6:1
Later on, an instruction with a debug location is scheduled above the
DBG_VALUE, effectively ending the prologue without a location for p1:
# *** IR Dump Before Post RA top-down list latency scheduler ***:
# Machine code for function foo: NoPHIs, TracksLiveness, NoVRegs
Frame Objects:
fi#-1: size=4, align=16, fixed, at location [SP+4]
bb.0.entry:
renamable $eax = MOV32rm $esp, 1, $noreg, 4, $noreg :: (load 4 from
%fixed-stack.0, align 16)
DBG_VALUE $esp, 0, !"p1", !DIExpression(DW_OP_plus_uconst, 4),
debug-location !20; lst.c:3:15 line no:3 indirect
renamable $ecx = MOV32rm $noreg, 1, $noreg, @g2, $noreg, debug-location
!21 :: (dereferenceable load 4 from @g2, !tbaa !22); lst.c:4:8
MOV32mr $noreg, 1, $noreg, @g1, $noreg, killed renamable $ecx,
debug-location !26 :: (store 4 into @g1, !tbaa !22); lst.c:4:6
MOV32mi killed renamable $eax, 1, $noreg, 0, $noreg, 0, debug-location
!27 :: (store 4 into %ir.p1, !tbaa !22); lst.c:5:7
RETL debug-location !28; lst.c:6:1
# *** IR Dump After Post RA top-down list latency scheduler ***:
# Machine code for function foo: NoPHIs, TracksLiveness, NoVRegs
Frame Objects:
fi#-1: size=4, align=16, fixed, at location [SP+4]
bb.0.entry:
renamable $ecx = MOV32rm $noreg, 1, $noreg, @g2, $noreg, debug-location
!21 :: (dereferenceable load 4 from @g2, !tbaa !22); lst.c:4:8
renamable $eax = MOV32rm $esp, 1, $noreg, 4, $noreg :: (load 4 from
%fixed-stack.0, align 16)
DBG_VALUE $esp, 0, !"p1", !DIExpression(DW_OP_plus_uconst, 4),
debug-location !20; lst.c:3:15 line no:3 indirect
MOV32mr $noreg, 1, $noreg, @g1, $noreg, killed renamable $ecx,
debug-location !26 :: (store 4 into @g1, !tbaa !22); lst.c:4:6
MOV32mi killed renamable $eax, 1, $noreg, 0, $noreg, 0, debug-location
!27 :: (store 4 into %ir.p1, !tbaa !22); lst.c:5:7
RETL debug-location !28; lst.c:6:1
Currently, DebugHandlerBase::beginFunction() will move up the debug value to
the start of the function, so the end results from Clang for this example will
be correct. However, in https://reviews.llvm.org/D57511 I'm looking into
removing that code, as it can move debug values over their defining
instructions.
The lexical-scope trimming is done to avoid unnecessary DBG_VALUEs being
emitted:
// The computed intervals may extend beyond the range of the debug
// location's lexical scope. In this case, splitting of an interval
// can result in an interval outside of the scope being created,
// causing extra unnecessary DBG_VALUEs to be emitted. To prevent
// this, trim the intervals to the lexical scope.
In this case, keeping the DBG_VALUE at the start of the function does not
result in extra DBG_VALUEs. Can the trimming perhaps be made more selective, so
it avoids situations like this for parameters? Or should this be solved in
another way?
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190207/c69a60a8/attachment.html>
More information about the llvm-bugs
mailing list