This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]