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


> PR 33848, a 4.2 regression on MIPS, is about cases in which we have
> a branch like:
>
>     if (foo == &&bar)
>
> and in which the register that holds &&bar is not allocated a hard
> register. Reload rematerialises the load of &&bar, first replacing the
> pseudo register with the label, then replacing the label with a reload
> register.  The second step triggers the following code in
> reload.c:subst_reloads:
>
> 	  /* If we're replacing a LABEL_REF with a register, add a
> 	     REG_LABEL note to indicate to flow which label this
> 	     register refers to.  */
> 	  if (GET_CODE (*r->where) == LABEL_REF
> 	      && JUMP_P (insn))
> 	    {
> 	      REG_NOTES (insn) = gen_rtx_INSN_LIST (REG_LABEL,
> 						    XEXP (*r->where, 0),
> 						    REG_NOTES (insn));
> 	      JUMP_LABEL (insn) = XEXP (*r->where, 0);
> 	   }
>
> So we end up replacing the jump's real JUMP_LABEL with bar, and
> cfgcleanup later deletes the real target as dead.

Yes, this is relatively recent, the original code didn't modify JUMP_LABEL.

> H-P fixed this properly on mainline by splitting REG_LABEL into
> REG_LABEL_OPERAND and REG_LABEL_TARGET.  Unfortunately, I think that's
> too invasive to backport.

Agreed.  Moreover H-P's patch still has unresolved issues.

> And since JUMP_LABEL should now always be valid before reload, I think we
> should only add a REG_LABEL note when the label is the same as the current
> JUMP_LABEL.  Calling rebuild_jump_labels immediately after reload
> would then be a no-op for this particular insn, just as it should be.

Can't we nevertheless imagine a JUMP_P insn reaching here without JUMP_LABEL?

> If so, should I install the testcase on mainline too?

I think that the testsuite should increase monotically.

-- 
Eric Botcazou


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