This is the mail archive of the
mailing list for the GCC project.
Re: [4.2 only] RFA: PR 33848: reload rematerialisation of labels
- From: Richard Sandiford <rsandifo at nildram dot co dot uk>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: ebotcazou at libertysurf dot fr (Eric Botcazou), gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com
- Date: Mon, 12 Nov 2007 21:19:39 +0000
- Subject: Re: [4.2 only] RFA: PR 33848: reload rematerialisation of labels
- References: <200711122039.lACKdRfU008173@d12av02.megacenter.de.ibm.com>
Thanks for looking at this. (Sorry Mark: my message and Ulrich's crossed.)
"Ulrich Weigand" <firstname.lastname@example.org> writes:
> Richard Sandiford wrote:
>> Eric Botcazou <email@example.com> 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.