Re: [Patch, PR 54128] ira.c change to fix mips bootstrap

[Steve Ellcey <sellcey at mips dot com>]

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
sje@cup.hp.com