[llvm-dev] globalisel: cross-bank constant propagation?

[Nicolai Hähnle via llvm-dev]

On Mon, Mar 29, 2021 at 3:34 PM Jay Foad <jay.foad at gmail.com> wrote:

> On Mon, 29 Mar 2021 at 14:04, Matt Arsenault <arsenm2 at gmail.com> wrote:
> > > On Mar 27, 2021, at 04:56, Jay Foad via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > >
> > > Hi Nicolai!
> > >
> > > For simplicity our regbankselect says that all operands of VALU
> > > instructions have to go in vgprs. Moving some of them into sgprs is
> > > left as an optimisation for a later pass. As you know there are limits
> > > on //how many// operands of a VALU instruction can be sgprs or
> > > constants, which are not simple to express in terms of alternative
> > > operand mappings.
> > >
> > > Thanks,
> > > Jay.
> >
> >
> > There are 2 issues:
> > 1. Current RegBankSelect does not consider the uses when selecting the
> bank. This is a general missing optimization
> > 2. For the AMDGPU case, I think we should have a post-regbankselect
> combiner for this. It’s often better to materialize constants for each bank
>

This sounds desirable, but how would this work on GMIR without interfering
in strange ways with pattern matching?

The challenge I see is: due to the constant bus limitation, there are
situations in which such a combiner has to make a choice as to which
operand to combine / eliminate the COPY. If the choice is arbitrary, it may
sometimes inhibit later pattern matching.

Related: are we clear on what is legal for GMIR? If G_ADD of regbank sgpr
into regbank vgpr is supposed to be legal, does it then have to satisfy the
constant bus limitation? If so, why are we still calling it G_ADD instead
of V_ADD?



> >
> > I don’t think we actually want to have to look through copies, and the
> places we do are just working around the status quo.
> >
> > The folding SGPR/constants into instructions should be a new and
> improved version of SIFoldOperands. I think optimizing this is beyond the
> scope of what RegBankSelect and selection patterns. Far too much code would
> need to be taught to respect and preserve the constant bus limitation
> otherwise, so that’s why everything uses VGPRs.
>
> I can understand leaving it to a later pass to fold //sgprs or
> constants// into an instruction. What I can't understand is how you do
> the same kind of thing for more complex selection patterns like:
>
>   t:sgpr = G_ADD y:sgpr, z:sgpr
>   t':vgpr = COPY t:sgpr
>   r:vgpr = G_ADD x:vgpt, t':vgpr
>
> How can we select v_add3_u32 from this? I can only think of two options:
>
> 1. Select s_add and v_add and leave it to a later pass to combine
> them. This seems to be giving up on doing decent pattern-based
> instruction selection.
> 2. Match it in the instruction selector, using a pattern that
> (explicitly or implicitly) looks through the cross-bank copy. But then
> you're back to the problem that two of the inputs are sgprs, which may
> or may not be valid according to complex operand restrictions.
>

The SelectionDAG pattern for v_add3 and friends already checks this using a
C++ code fragment, doesn't it?

Cheers,
Nicolai


>
> Thanks,
> Jay.
>


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210329/0bdd8d63/attachment.html>