On the following testcase I wonder if VTA couldn't help a little bit with
debugging experience.
(insn 6 5 7 2 prNNNNN.c:17 (set (mem/c/i:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [2 b+0 S8 A64])
(const_int 0 [0x0])) 89 {*movdi_1_rex64} (nil))
(insn 7 6 8 2 prNNNNN.c:18 (set (mem/c/i:DI (reg/f:DI 7 sp) [2 c+0 S8 A128])
(const_int 0 [0x0])) 89 {*movdi_1_rex64} (nil))
(insn 8 7 26 2 prNNNNN.c:19 (set (reg/f:DI 4 si [60])
(reg/f:DI 7 sp)) 89 {*movdi_1_rex64} (expr_list:REG_EQUIV (plus:DI
(reg/f:DI 7 sp)
(const_int 0 [0x0]))
(nil)))
(insn 26 8 12 2 prNNNNN.c:19 (set (reg/f:DI 5 di [61])
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8]))) 248 {*lea_1} (nil))
(call_insn 12 26 14 2 prNNNNN.c:19 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("foo") [flags 0x3] <function_decl
0x7f5d5f9b8a00 foo>) [0 S1 A8])
(const_int 0 [0x0]))) 903 {*call_value_0_rex64} (expr_list:REG_DEAD
(reg:DI 5 di)
(expr_list:REG_DEAD (reg:DI 4 si)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
(nil))))
is before scheduling and that is well debuggable. But scheduling changes this
to:
(insn:TI 26 28 8 2 prNNNNN.c:19 (set (reg/f:DI 5 di [61])
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8]))) 248 {*lea_1} (nil))
(insn 8 26 6 2 prNNNNN.c:19 (set (reg/f:DI 4 si [60])
(reg/f:DI 7 sp)) 89 {*movdi_1_rex64} (expr_list:REG_EQUIV (plus:DI
(reg/f:DI 7 sp)
(const_int 0 [0x0]))
(nil)))
(insn 6 8 7 2 prNNNNN.c:17 (set (mem/c/i:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [2 b+0 S8 A64])
(const_int 0 [0x0])) 89 {*movdi_1_rex64} (nil))
(insn:TI 7 6 12 2 prNNNNN.c:18 (set (mem/c/i:DI (reg/f:DI 7 sp) [2 c+0 S8
A128])
(const_int 0 [0x0])) 89 {*movdi_1_rex64} (nil))
(call_insn:TI 12 7 14 2 prNNNNN.c:19 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("foo") [flags 0x3] <function_decl
0x7f5d5f9b8a00 foo>) [0 S1 A8])
(const_int 0 [0x0]))) 903 {*call_value_0_rex64} (expr_list:REG_DEAD
(reg:DI 5 di)
(expr_list:REG_DEAD (reg:DI 4 si)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
(nil))))
Thus, putting a breakpoint on the foo line means that variables b and c aren't
initialized (that's fine) and are shown as <optimized out>, as the var_location
note is inserted after the line 17 resp. 18 stores. If at least for the simple
cases scheduling could insert DEBUG_INSNs in those cases, telling that the
variable is 0, the debug experience would be better.
Though, it is unclear whether doing that always would be a good idea - if the
variable is live already before and it just gets a new value, with such
DEBUG_INSNs we could see the correct value in the debugger, but couldn't see
the right address of the variable, without them we could see the right address,
but not the right value. When it is the first definition of the variable it is
<optimized out> vs. a value without address, which is better, but the scheduler
couldn't figure that out.
--
Summary: debug info vs. scheduling
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43119
