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: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: rsandifo at nildram dot co dot uk (Richard Sandiford)
- Cc: ebotcazou at libertysurf dot fr (Eric Botcazou), gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com
- Date: Tue, 13 Nov 2007 22:14:39 +0100 (CET)
- Subject: Re: [4.2 only] RFA: PR 33848: reload rematerialisation of labels
Richard Sandiford wrote:
> "Ulrich Weigand" <email@example.com> writes:
> > 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.
Hmm, you're right; the count cannot reach zero when it shouldn't.
However, the reverse can occur: if delete_insn is called on that
insn after it was modified by reload, LABEL_N_USES will *not* be
decremented, even though it should have been, and thus the label
might not get removed even though it should be ...
This doesn't seem as serious as the reverse problem; but I think
we've seen actual bugs in the past due to labels that were not
In any case, it just seems more conservative to me to add the note.
It keeps holding the (existing) LABEL_N_USES count; and it is what
the code is currently doing.
I'm not sure I've really understood why you're opposed to adding the
note; would you mind explaining again what your concerns are?
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE