[PATCH] D80065: AMDGPU: Fix illegally constant folding from V_MOV_B32_sdwa

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 18 10:49:18 PDT 2020


arsenm added a comment.

In D80065#2042115 <https://reviews.llvm.org/D80065#2042115>, @rampitec wrote:

> In D80065#2042113 <https://reviews.llvm.org/D80065#2042113>, @arsenm wrote:
>
> > In D80065#2042073 <https://reviews.llvm.org/D80065#2042073>, @rampitec wrote:
> >
> > > Technically even SDWA or DPP for can move immediate, aren't they? I.e.:
> > >
> > >   v_mov_b32_sdwa v0, 1 dst_sel:DWORD dst_unused:UNUSED_PRESERVE src0_sel:DWORD ; encoding: [0xf9,0x02,0x00,0x7e,0x81,0x16,0x86,0x00]
> > >
> > >
> > > Should not SDWA peephole be fixed instead? Interpretation of modifiers as materialized immediate seems to be just a bug.
> >
> >
> > We shouldn't emit a simple immediate materialize using SDWA in the first place, so it's not worth the complexity of trying to handle it
> >
> > > Moreover, we seem to have another bug in v_mov_b32:
> > > 
> > >   <stdin>:1:15: error: not a valid operand.
> > >   v_mov_b32 v0, -v1
> > > 
> > > 
> > > This is a legal form but we do not support it. If we fix that then we probably will have issue with src0_modifiers again, right?
> >
> > I think I saw a note before that v_mov_b32 doesn't actually support a VOP3 encoding, so I'm not sure it's valid. We never emit V_MOV_B32_e64 anyway
>
>
> It looks like it does support VOP3 form. I can encode 'v_mov_b32 v0, 100'.


That's still VOP1 with literal


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80065/new/

https://reviews.llvm.org/D80065





More information about the llvm-commits mailing list