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

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

Thanks for looking at this.  (Sorry Mark: my message and Ulrich's crossed.)

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> Richard Sandiford wrote:
>> Eric Botcazou <ebotcazou@libertysurf.fr> writes:
>> > Sorry, I don't seem to be able to make up my mind about this affair or
>> > clearly formulate what I'm afraid of.  The thing is, it's reload and
>> > I'll never feel comfortable with patching it on a release branch.  So
>> > I'd suggest to run this by some other maintainer (RTH?), setting aside
>> > the current thread.
>> 
>> Understood, thanks.  I'll probably wait a few days to see if anyone
>> volunteers before I pick a victim.
>
> Richard asked me to have at look at this issue.  Unfortunately, I don't
> see any real solution either (except back-porting the full H-P patch).
>
> Looking at the problem from the perspective of finding the most
> conservative change, I can see a number of things we should clearly
> *not* do:
>
> - Change a non-NULL JUMP_LABEL to something else.
>   (Reload must never actually change control flow.)
>
> - Create a jump_insn with REG_LABEL but NULL JUMP_LABEL.
>   (This is inconsistent, as Richard points out.)
>
> - More generally, create an insn that a future run of
>   rebuild_jump_labels would modify.
>
> But we also should not simply remove an explicit reference to
> a label *without* adding a REG_LABEL note, as this could screw
> up reference counting on the label and potentially cause it to
> be deleted (even though it is still referenced) -- e.g. if the
> label has been pushed into the literal pool.

I don't think this can happen.  The LABEL_N_USES count isn't affected
by reload's substitution, so that count should stay accurate until
the next call to rebuild_jump_labels.  Before that call, we should
never (modulo bugs) reach a situation in which LABEL_N_USES becomes
zero and in which this insn still needs it.

rebuid_jump_labels deletes all existing non-jump REG_LABELs and rebuilds
them from scratch.  It also recalculates LABEL_N_USES from scratch.
It never looks at pre-existing REG_LABEL notes when recalculating
the new value of LABEL_N_USES.  Instead, it relies on every label
reference being in the insn patterns in some form, either directly,
or through a literal pool access (which it then dereferences).

So in the particular example you give, we would reference-count
the label by looking through the literal pool MEM, and this would
be unaffected by any REG_LABEL note.

Richard