This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4.2 only] RFA: PR 33848: reload rematerialisation of labels
Eric Botcazou <ebotcazou@libertysurf.fr> writes:
>> 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.
Because (a) reload can turn a direct jump into an indirect jump with
a known target and (b) JUMP_LABEL should always be recomputable from
other information (as done by rebuild_jump_labels). Without the note,
later passes would not be able to recompute the correct JUMP_LABEL.
Richard