On Mon, Jun 21, 2021 at 11:59 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Mon, Jun 21, 2021 at 11:19:12AM +0200, Richard Biener wrote:
> > > --- gcc/config/i386/i386.c.jj 2021-06-21 09:39:21.622487840 +0200
> > > +++ gcc/config/i386/i386.c 2021-06-21 10:21:12.389794740 +0200
> > > @@ -15186,6 +15186,33 @@ ix86_lea_for_add_ok (rtx_insn *insn, rtx
> > > return ix86_lea_outperforms (insn, regno0, regno1, regno2, 0, false);
> > > }
> > >
> > > +/* Return true if insns before FIRST_INSN (which is of the form
> > > + (set (memory) (zero_operand)) are all also either in the
> > > + same form, or (set (zero_operand) (const_int 0)). */
> > > +
> > > +bool
> > > +ix86_zero_stores_peep2_p (rtx_insn *first_insn, rtx zero_operand)
> > > +{
> > > + rtx_insn *insn = first_insn;
> > > + for (int count = 0; count < 512; count++)
> >
> > Can't the peephole add a note (reg_equal?) that the
> > SET_SRC of the previously matched store is zero?
>
> I think REG_EQUAL is not valid, the documentation says that it should
> be used on SET of a REG, which is not the case here - we have a MEM.
>
> > That would avoid the need to walk here.
>
> But we could do what I've done in
> r11-7694-gd55ce33a34a8e33d17285228b32cf1e564241a70
> - have int ix86_last_zero_store_uid;
> set to INSN_UID of the last store emitted by the peephole2s and
> then check that INSN_UID against the var.
Hmm, or have reg_nonzero_bits_for_peephole2 () and maintain
that somehow ... (conservatively drop it when a SET is seen).
> Jakub
>
