On Wed, 2012-09-05 at 08:15 +0200, Jakub Jelinek wrote:
> The debug insns generally shouldn't extend the lifetime of pseudos (see the
> valtrack.c stuff), so if you hit this, there is probably some earlier bug
> that didn't reset/adjust the debug insns in question.
> I'm not saying the ira.c patch is absolutely a bad idea, but it would be
> good if you could investigate where those debug insns started extending
> lifetime of pseudos.
I am not sure I know how to do that. I am also not sure the problem is
with extending the life of a psuedo register or if it is in recognizing
that a hard register is dead. $2, the register that doesn't get reused
when generating debug code is the register used to return values. In
this case I am returning a 64 bit integer value (step_c) that is split
across two registers ($2 and $3). In the ira dump file I don't see any
debug instructions referring to $3, but I do have one for $2. The
debug_insn for $2 first shows up in the cse1 phase and there is no
debug_insn for $3, perhaps because we only use the lower half of the
return value.
(debug_insn 73 25 72 5 (var_location:SI D#1 (reg:SI 2 $2)) -1
(nil))
(insn 72 73 27 5 (set (reg:SI 224 [ step_c+4 ])
(reg:SI 3 $3 [orig:2+4 ] [2])) x.i:58 282 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 3 $3 [orig:2+4 ] [2])
(nil)))
(debug_insn 27 72 28 5 (var_location:DI step_c (concatn/v:DI [
(debug_expr:SI D#1)
(reg:SI 224 [ step_c+4 ])
])) x.i:58 -1
(nil))
It seems odd to have a concatn where one element is a debug_expr and the other
is a register. But I don't know if this is a problem or a normal way of
handling
functions that return a value in two registers.
Steve Ellcey
s...@cup.hp.com
