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

Hi,

While experimenting with alternative ways of lowering funnel shifts on
AMDGPU I have run into a case where this GMIR:

    %0:vgpr(s32) = COPY $vgpr0
    %1:vgpr(s32) = COPY $vgpr1
    %2:sgpr_64 = COPY $sgpr30_sgpr31
    %3:sgpr(s32) = G_CONSTANT i32 5
    %7:vgpr(s64) = G_MERGE_VALUES %1(s32), %0(s32)
    %9:vgpr(s32) = COPY %3(s32)
    %8:vgpr(s64) = G_LSHR %7, %9(s32)
    %4:vgpr(s32) = G_TRUNC %8(s64)
    $vgpr0 = COPY %4(s32)
    %5:ccr_sgpr_64 = COPY %2
    S_SETPC_B64_return %5, implicit $vgpr0

does not get matched by this selection pattern:

def : GCNPat<(i32 (trunc (srl i64:$src0, (i32 ShiftAmt32Imm:$src1)))),
          (V_ALIGNBIT_B32_e64 (i32 (EXTRACT_SUBREG VReg_64:$src0, sub1)),
                          (i32 (EXTRACT_SUBREG VReg_64:$src0, sub0)),
VSrc_b32:$src1)>;

because the COPY of G_CONSTANT 5 from sgpr to vgpr gets in the way of
matching the (i32 ShiftAmt32Imm:$src1).

What's a good way of fixing this? I know there has been some
discussion before about whether the generated matcher should look
through copies, either automatically or only when the tablegen pattern
is augmented with some kind of "please look through copies here" node.

As an alternative, would it make sense to run some cross-bank constant
propagation after regbankselect? It seems pretty obvious to me that %9
above should be simplified to:

%9:vgpr(s32) = G_CONSTANT i32 5

so long as it's legal, which we can easily check, can't we?

Thanks,
Jay.

Hi Jay,

Where does the copy of a constant from SGPR to VGPR come from? Naively, I'd
think that better GMIR would be

    %3:sgpr(s32) = G_CONSTANT i32 5
    ...
    %8:vgpr(s64) = G_LSHR %7, %3(s32)

Cheers,
Nicolai

On Fri, Mar 26, 2021 at 3:43 PM Jay Foad via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> While experimenting with alternative ways of lowering funnel shifts on
> AMDGPU I have run into a case where this GMIR:
>
>     %0:vgpr(s32) = COPY $vgpr0
>     %1:vgpr(s32) = COPY $vgpr1
>     %2:sgpr_64 = COPY $sgpr30_sgpr31
>     %3:sgpr(s32) = G_CONSTANT i32 5
>     %7:vgpr(s64) = G_MERGE_VALUES %1(s32), %0(s32)
>     %9:vgpr(s32) = COPY %3(s32)
>     %8:vgpr(s64) = G_LSHR %7, %9(s32)
>     %4:vgpr(s32) = G_TRUNC %8(s64)
>     $vgpr0 = COPY %4(s32)
>     %5:ccr_sgpr_64 = COPY %2
>     S_SETPC_B64_return %5, implicit $vgpr0
>
> does not get matched by this selection pattern:
>
> def : GCNPat<(i32 (trunc (srl i64:$src0, (i32 ShiftAmt32Imm:$src1)))),
>           (V_ALIGNBIT_B32_e64 (i32 (EXTRACT_SUBREG VReg_64:$src0, sub1)),
>                           (i32 (EXTRACT_SUBREG VReg_64:$src0, sub0)),
> VSrc_b32:$src1)>;
>
> because the COPY of G_CONSTANT 5 from sgpr to vgpr gets in the way of
> matching the (i32 ShiftAmt32Imm:$src1).
>
> What's a good way of fixing this? I know there has been some
> discussion before about whether the generated matcher should look
> through copies, either automatically or only when the tablegen pattern
> is augmented with some kind of "please look through copies here"
node.
>
> As an alternative, would it make sense to run some cross-bank constant
> propagation after regbankselect? It seems pretty obvious to me that %9
> above should be simplified to:
>
> %9:vgpr(s32) = G_CONSTANT i32 5
>
> so long as it's legal, which we can easily check, can't we?
>
> Thanks,
> Jay.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
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/20210327/87aa5b94/attachment.html>