Re: [PATCH 02/12] Allow generating pseudo register with specific alignment

[Richard Biener <richard.guenther@gmail.com>]

On Mon, May 10, 2021 at 4:12 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, May 10, 2021 at 6:59 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Mon, May 10, 2021 at 3:29 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Mon, May 10, 2021 at 2:39 AM Richard Sandiford
> > > <richard.sandiford@arm.com> wrote:
> > > >
> > > > Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > > > > On Fri, Apr 30, 2021 at 8:30 PM Richard Sandiford via Gcc-patches
> > > > > <gcc-patches@gcc.gnu.org> wrote:
> > > > >>
> > > > >> "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> writes:
> > > > >> > On Fri, Apr 30, 2021 at 5:49 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >> >>
> > > > >> >> On Fri, Apr 30, 2021 at 5:42 AM Richard Sandiford
> > > > >> >> <richard.sandiford@arm.com> wrote:
> > > > >> >> >
> > > > >> >> > "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> writes:
> > > > >> >> > > On Fri, Apr 30, 2021 at 2:06 AM Richard Sandiford
> > > > >> >> > > <richard.sandiford@arm.com> wrote:
> > > > >> >> > >>
> > > > >> >> > >> "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> writes:
> > > > >> >> > >> > gen_reg_rtx tracks stack alignment needed for pseudo registers so that
> > > > >> >> > >> > associated hard registers can be properly spilled onto stack.  But there
> > > > >> >> > >> > are cases where associated hard registers will never be spilled onto
> > > > >> >> > >> > stack.  gen_reg_rtx is changed to take an argument for register alignment
> > > > >> >> > >> > so that stack realignment can be avoided when not needed.
> > > > >> >> > >>
> > > > >> >> > >> How is it guaranteed that they will never be spilled though?
> > > > >> >> > >> I don't think that that guarantee exists for any kind of pseudo,
> > > > >> >> > >> except perhaps for the temporary pseudos that the RA creates to
> > > > >> >> > >> replace (match_scratch …)es.
> > > > >> >> > >>
> > > > >> >> > >
> > > > >> >> > > The caller of creating pseudo registers with specific alignment must
> > > > >> >> > > guarantee that they will never be spilled.   I am only using it in
> > > > >> >> > >
> > > > >> >> > >   /* Make operand1 a register if it isn't already.  */
> > > > >> >> > >   if (can_create_pseudo_p ()
> > > > >> >> > >       && !register_operand (op0, mode)
> > > > >> >> > >       && !register_operand (op1, mode))
> > > > >> >> > >     {
> > > > >> >> > >       /* NB: Don't increase stack alignment requirement when forcing
> > > > >> >> > >          operand1 into a pseudo register to copy data from one memory
> > > > >> >> > >          location to another since it doesn't require a spill.  */
> > > > >> >> > >       emit_move_insn (op0,
> > > > >> >> > >                       force_reg (GET_MODE (op0), op1,
> > > > >> >> > >                                  (UNITS_PER_WORD * BITS_PER_UNIT)));
> > > > >> >> > >       return;
> > > > >> >> > >     }
> > > > >> >> > >
> > > > >> >> > > for vector moves.  RA shouldn't spill it.
> > > > >> >> >
> > > > >> >> > But this is the point: it's a case of hoping that the RA won't spill it,
> > > > >> >> > rather than having a guarantee that it won't.
> > > > >> >> >
> > > > >> >> > Even if the moves start out adjacent, they could be separated by later
> > > > >> >> > RTL optimisations, particularly scheduling.  (I realise pre-RA scheduling
> > > > >> >> > isn't enabled by default for x86, but it can still be enabled explicitly.)
> > > > >> >> > Or if the same data is being copied to two locations, we might reuse
> > > > >> >> > values loaded by the first copy for the second copy as well.
> > > > >> >
> > > > >> > There are cases where pseudo vector registers are created as pure
> > > > >> > temporary registers in the backend and they shouldn't ever be spilled
> > > > >> > to stack.   They will be spilled to stack only if there are other non-temporary
> > > > >> > vector register usage in which case stack will be properly re-aligned.
> > > > >> > Caller of creating pseudo registers with specific alignment guarantees
> > > > >> > that they are used only as pure temporary registers.
> > > > >>
> > > > >> I don't think there's really a distinct category of pure temporary
> > > > >> registers though.  The things I mentioned above can happen for any
> > > > >> kind of pseudo register.
> > > > >
> > > > > I wonder if for the cases HJ thinks of it is appropriate to use hardregs?
> > > > > Do we generally handle those well?  That is, are they again subject
> > > > > to be allocated by RA when no longer live?
> > > >
> > > > Yeah, using hard registers should work.  Of course, any given fixed choice
> > > > of hard register has the potential to be suboptimal in some situation,
> > > > but it should be safe.
> > >
> > > I tried hard registers.  The generated code isn't as good as pseudo registers.
> > > But I want to avoid align the shack when YMM registers are only used to
> > > inline memcpy/memset.  Any suggestions?
> >
> > I wonder if we can mark pseudos with a new reg flag, like 'nospill' and
> > enforce this in LRA or ICE if we can't?  That said, we should be able
> > to verify our assumption holds.  Now, we then of course need to avoid
> > CSE re-using such pseudo in ways that could lead to spilling
> > (not sure how that could happen, but ...).
>
> Spill should be rare.  It is up to backends to decide if unaligned spill
> should be used when spill does happen.

Can we transparently decide this somehow?  Thus when we didn't
do stack re-alignment force unaligned spills?

> > Did you investigate closer what made the hardreg case generate worse
> > code?  Can we hide the copies behind UNSPECs and split them late
>
> I chose XMM7 for memcpy/memset.   Only XMM7 is used for memcpy
> vs XMM0/XMM1/.....
>
> > after reload?  Or is that too awkward to support when generating the
> > sequence from the middle-end (I suppose it's not going via the optabs?)
>
> That is correct.
>
> > Richard.
> >
> > > Thanks.
> > >
> > > --
> > > H.J.
>
>
>
> --
> H.J.