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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Richard Sandiford wrote:
> "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.

OK, I see.

> Is that convincing enough?  I.e. does...
> 
> > Thanks for your explanations; the patch looks OK to me now.
> 
> ...this still hold?

Yes, it does.   The patch is OK.


Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com