[4.2 only] RFA: PR 33848: reload rematerialisation of labels

[Richard Sandiford]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> Richard Sandiford wrote:
>> I don't think adding a REG_LABEL note would make any difference as
>> far as that's concerned either, at least not in the situations we
>> care about.
>
> Hmmm, right.  I think that means refcounting is probably wrong, but
> it would be wrong no matter whether we add the REG_LABEL or not ...
>
> OK, I guess you've convinced me that the presence or absence of a
> REG_LABEL note on a jump with JUMP_LABEL only ever affects the return
> value of computed_jump_p on that insn.
>
> (There is one remaining use of REG_LABEL that I'm not 100% certain of,
> and that is the one in reorg.c:emit_delay_sequence.  I think jumps 
> like that probably are not eligible to be in delay slots, but I'm
> not completely certain about that ...)

I'm not completely certain whether jumps like that can appear or
not either, but I don't think it matters.  The code you mention is
incrementing the label count in cases where we've copied an insn.
If that insn is the type of jump we're considering, we already know
that the deletion routines will not decrement the label count for
REG_LABEL notes.  So if a label is referenced in the way we're
considering, the count can never become zero before the next call
to rebuild_jump_labels.

Likewise, while the label is also the target of another jump,
the count can never become 1 before the next call to rebuild_jump_labels.
Checks of the form "LABEL_NUSES (JUMP_LABEL (foo)) == 1" will therefore
always be false.

Is that convincing enough?  I.e. does...

> Thanks for your explanations; the patch looks OK to me now.

...this still hold?

(I'm not guaranteeing that this isn't going to tickle latent problems.
I'm just arguing that it's more conservative than the alternative.)

Richard