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: Wed, 14 Nov 2007 01:24:35 +0100 (CET)
- Subject: Re: [4.2 only] RFA: PR 33848: reload rematerialisation of labels
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 ...)
> As I see it, 4.2 effectively uses label notes on jumps only for encoding
> the target, so adding a note for something that isn't the target seems
> inherently dangerous. It's what bit us in this PR. I'm afraid that
> if we keep the note in any other case, we won't actually have a good
> theoretical bases for doing it, and the same sort of bug could resurface
> in other situations.
Right. If computed_jump_p is indeed the only difference, I agree it
would be more conservative to *not* add the REG_LABEL; better if the
jump is considered computed even though it always goes to the same
target, than if the jump is considered to have a target that might
actually be incorrect.
Thanks for your explanations; the patch looks OK to me now.
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE