[PATCH][rtl-optimization] Fix PR23726
Björn Haase
bjoern.m.haase@web.de
Thu Sep 8 17:47:00 GMT 2005
Richard Sandiford wrote on Donnerstag, 8. September 2005 13:04 :
> Björn Haase <bjoern.m.haase@web.de> writes:
> > + /* The following lines correspond *exactly* to what would have been
> > + * expanded by use of above template. Only difference is that below
> > + * register notes are added that help to implement optimizations. */
> > + rtx annotate_me;
> > + rtx note;
> > +
> > + emit_insn (gen_rtx_SET (VOIDmode,gen_rtx_REG
> > (QImode,24),operands[1])); + emit_insn (gen_rtx_SET
> > (VOIDmode,gen_rtx_REG (QImode,22),operands[2])); + emit
> > (gen_rtx_PARALLEL (VOIDmode,
> > + gen_rtvec (4,
> > + gen_rtx_SET (VOIDmode,gen_rtx_REG (QImode,24),
> > + gen_rtx_DIV (QImode,gen_rtx_REG (QImode,24),
> > + gen_rtx_REG
> > (QImode,22))), + gen_rtx_SET (VOIDmode,gen_rtx_REG (QImode,25),
> > + gen_rtx_MOD (QImode,gen_rtx_REG (QImode,24),
> > + gen_rtx_REG
> > (QImode,22))), + gen_hard_reg_clobber (QImode, 22),
> > + gen_hard_reg_clobber (QImode, 23))));
> > +
> > + annotate_me =
> > + emit_insn (gen_rtx_SET (VOIDmode,operands[0],gen_rtx_REG
> > (QImode,24))); + note = gen_rtx_fmt_ee (DIV,QImode,
> > + copy_rtx (operands[1]),
> > + copy_rtx (operands[2]));
> > + set_unique_reg_note (annotate_me, REG_EQUAL, note);
> > +
> > + annotate_me =
> > + emit_insn (gen_rtx_SET (VOIDmode,operands[3],gen_rtx_REG
> > (QImode,25))); + note = gen_rtx_fmt_ee (MOD,QImode,
> > + copy_rtx (operands[1]),
> > + copy_rtx (operands[2]));
> > + set_unique_reg_note (annotate_me, REG_EQUAL, note);
>
> I don't think this is valid in general. rtl semantics say that
> the values are read before either operand is written. For example,
> operands[0] might overlap operands[1] or operands[2], in which case
> the second REG_EQUAL will be incorrect.
>
> Richard
Thank you for reviewing the patch!
I agree with you that your objection is justified. However, given the known
structure of the expander, the content of the notes is correct after
expansion: We know that the operands do *not* overlap initially. Open
question is: If this is true initially, could that be wrong later on?
A problem can then show up only when starting to renumber the pseudos. E.g.
when renumbering them to hard regs.
So I agree that the method I have suggested has a possible problem since it
bases on the implicit assumption: "If a pseudo is given a new number, all
register notes referring to this pseudo will be deleted."
So this assumption needs to be checked. After what I have seen, it seems that
it is true for register allocation.
Open question for me is: Is there another known place apart from register
allocation where pseudos could end up to be renumbered?
Bjoern
More information about the Gcc-patches
mailing list