This is the mail archive of the gcc-patches@gcc.gnu.org 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


> I don't think it would reopen the original wound.  The change was for
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606, and as Andrew says
> in comment #3:
>
> ------------------------------------------------------------------------
> (In reply to comment #2)
>
> > Why is computed_jump_p (insn) not returning true?
>
> Actually it is the following insn:
> (jump_insn 169 222 170 19 (set (pc)
>         (reg:DI 0 ax)) 515 {*indirect_jump_rtx64} (nil)
>     (insn_list:REG_LABEL 172 (nil)))
>
> Which is a computed goto but at this point we have a REG_LABEL which
> causes computed_jump_p to return false
> ------------------------------------------------------------------------
>
> In other words, by unconditionally adding a REG_LABEL note, regardless
> of whether there was a JUMP_LABEL, reload was turning something that
> satisfied computed_jump_p into something that was neither a computed
> jump nor a correct register-indirect jump to a known target.

I'm not so concerned about computed_jump_p as about the original intent of the 
code, which was added by Alexandre for SH5:
  http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00176.html

> My patch fixes the same bug by making sure that we only attach
> a REG_LABEL note to jumps that already have a known target.

But what's the point in attaching a REG_LABEL note if JUMP_LABEL already 
points to the same label?  My understanding is that Alexandre's change was 
meant to add the note on jumps without JUMP_LABEL.

-- 
Eric Botcazou


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