Misleading error message when trying to use v128-v255 in VOPC encoding

[Pierre-vh]

On GFX10, this seems to be allowed:

echo "v_cmp_gt_u16 s2, v128" | /opt/rocm/llvm/bin/llvm-mc -arch=amdgcn -mcpu=gfx1030 -show-encoding  -show-inst

But on GFX11, this results in an error:

echo "v_cmp_gt_u16 s2, v128" | /opt/rocm/llvm/bin/llvm-mc -arch=amdgcn -mcpu=gfx1100 -show-encoding  -show-inst

This appears to be an intentional limit added in https://reviews.llvm.org/D133723 - VOPC cannot encode registers >v127.
However, users could simply use the VOP3 encoding and use those registers just fine. For that, all they need to do is pass an explicit destination register (instead of the implied VCC), e.g.
v_cmp_gt_u16 vcc, s2, v128

Desired outcome:

A better error message indicating that the VOP3 variant of the instruction needs to be used would be helpful.

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

[Pierre-vh]

Note: This isn't straightforward though because when the instruction fails to parse, MatchAndEmitInstruction doesn't tell us what the opcode is. It just tells us the register operands and the mnemonic as a string.

We could diagnose it like this:

static bool isTrue16VOPCInvalidSrc(const OperandVector &Operands) {
  if(Operands.size() != 3)
    return false;

  StringRef Mnemo = static_cast<const AMDGPUOperand*>(Operands[0].get())->getToken();
  if(!Mnemo.contains("b16") && !Mnemo.contains("u16") && !Mnemo.contains("f16"))
    return false;

  unsigned R1 = Operands[1]->getReg();
  unsigned R2 = Operands[2]->getReg();
  return (R1 > AMDGPU::VGPR127 && R1 <= AMDGPU::VGPR255) || (R2 > AMDGPU::VGPR127 && R2 <= AMDGPU::VGPR255);
}

But it's hacky.
@dpreobra do you have any idea to improve this?

[dpreobra]

Yes, when the instruction fails to parse there is not much we can do. Your hack (with minor corrections) might work, and I do not see how to make it much simpler.

You may have noticed that v_cmp opcodes with explicitly specified vcc operand are encoded as VOPC, but automatically promoted to VOP3 when needed:

// VOPC
v_cmp_gt_u16 vcc_lo, s2, v127       ; encoding: [0x02,0xfe,0x78,0x7c]

// VOP3
v_cmp_gt_u16 vcc_lo, s2, v128       ; encoding: [0x6a,0x00,0x3c,0xd4,0x02,0x00,0x03,0x00]

This is the preferred and officially documented syntax - see https://llvm.org/docs/AMDGPU/AMDGPUAsmGFX10.html#vopc.

Unfortunately, instructions with implicit vcc are not promoted to VOP3 automatically.

Added @Sisyph for awareness.

[Sisyph]

While it is possible to infer vcc if no dst is provided for VOP3 forms, my feeling is that is not a desirable feature, since the dst could be any SGPR. The downside is inline asm which inferred vcc and used VGPRs above 127 on GFX10 need to be ported to GFX11 even if it is semantically the same. That process should be fairly simple to script. Instead of an error message, is there a logical place to note the behavior? Perhaps in the LLVM GFX11 changelog?

[dpreobra]

Instead of an error message, is there a logical place to note the behavior? Perhaps in the LLVM GFX11 changelog?

I'm currently working on GFX11 assembler syntax description similar to that for GFX10 I noted above. Hopefully, the description will make using 16-bit ops more clear.