llvm dev - Mar 2021 - globalisel: cross-bank constant propagation?

> 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

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.

-Matt

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
>
> 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.

Thanks,
Jay.