[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