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

[Jay Foad via llvm-dev]

On Sat, 27 Mar 2021 at 13:40, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On Sat, Mar 27, 2021 at 9:56 AM Jay Foad <jay.foad at gmail.com> wrote:
>> 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.
>
> Okay, that makes sense: the initial register bank selection is biased to generate legal code.
>
> It sounds likely that similar issues of obstructive COPYs will appear in other patterns as well, right? For example, if you have original code of the form (x * (-y)), where x is divergent and y is uniform, it seems likely you'd get something like (typed completely off the top of my head):
>
>   t:sgpr = G_FNEG y:sgpr
>   t':vgpr = COPY t:sgpr
>   r:vgpr = G_FMUL x:vgpt, t':vgpr
>
> ... and then an instruction selection pattern that pulls the negation into a source modifier would fail due to the COPY? The point is that this is not just an issue for constants, so a constant-specific pass seems the wrong way to go.

Yes, good point.

> The remaining options I see right now are:
>
> (1) Allow pattern matching to look through COPYs.
> (2) Eliminate those COPYs before instruction selection.
>
> Not having thought about this very long, the relative merits seem to be:
>
> - (2) results in smaller GMIR and a simpler pattern matcher, which is better for compile time
> - (2) requires legalization after(?) instruction selection (constant bus limit etc.), which is going to be a pain in the existing CodeGen framework
>
> Neither option makes me happy :)  I guess I would go with (2) if this was a greenfield development, but (1) fits better in the existing LLVM code base.

Here's a patch that tackles (1): https://reviews.llvm.org/D86294 . The
current version of the patch adds a dag operator that looks through
copies. I'm not particularly thrilled about that because as a pattern
writer I don't know when I would be required to use it, so I would
probably sprinkle it everywhere.

Previous versions of the same patch changed GlobalISel pattern
matching to look through copies automatically, without any special dag
operator. This seems much more user friendly to me, but Matt argued
that it "is selecting instructions incorrectly, and then relying on
something else to fix them up".

To be honest I am confused about the role of RegBankSelect when you
have instruction selection patterns that match more than one GMIR
node. How can RegBankSelect possibly tell you what alternative
mappings (i.e. instructions) are available, without predicting what
patterns will be matched by instruction selection?

Jay.