[AMDGPU] True16 .l/.h register operands not disassembled as such

[kosarev]

gfx1250_dasm_vop1.txt reads like the last operand is v127.l regardless of whether the True16 support is enabled or not:

0x7f,0xe5,0x0a,0x7e
# GFX1250: v_cvt_f32_bf16_e32 v5, v127.l           ; encoding: [0x7f,0xe5,0x0a,0x7e]

In gfx1250_asm_vop1.s the opposite is happening, with registers not being disassembled as .l/.h regardless of the True16 mode selected:

v_tanh_f16 v5, v1
// GFX1250: v_tanh_f16_e32 v5, v1                   ; encoding: [0x01,0x3f,0x0a,0x7e]

Caught on an attempt to turn these into round-tripping tests.

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Ivan Kosarev (kosarev)

gfx1250_dasm_vop1.txt reads like the last operand is `v127.l` regardless of whether the True16 support is enabled or not: ``` 0x7f,0xe5,0x0a,0x7e # GFX1250: v_cvt_f32_bf16_e32 v5, v127.l ; encoding: [0x7f,0xe5,0x0a,0x7e] ```

In gfx1250_asm_vop1.s the opposite is happening, with registers not being disassembled as .l/.h regardless of the True16 mode selected:

v_tanh_f16 v5, v1
// GFX1250: v_tanh_f16_e32 v5, v1                   ; encoding: [0x01,0x3f,0x0a,0x7e]

Caught on an attempt to turn these into round-tripping tests.

[broxigarchen]

Hi @rampitec these seems to be new insts added in gfx1250. Do you want me to look into this or do you have someone in mind who can take a look in this? Thanks!

[rampitec]

Fix for v_cvt_f32_bf16: #161578

[rampitec]

I do not see an issue with the v_tanh_f16 though:

$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding -mattr=+real-true16 <<< 'v_tanh_f16 v5.l, v1.l'
        v_tanh_f16_e32 v5.l, v1.l               ; encoding: [0x01,0x3f,0x0a,0x7e]
$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding -mattr=+real-true16 -mdis <<< 0x01,0x3f,0x0a,0x7e
        v_tanh_f16_e32 v5.l, v1.l               ; encoding: [0x01,0x3f,0x0a,0x7e]
$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding <<< 'v_tanh_bf16 v5, v1'
        v_tanh_bf16_e32 v5, v1                  ; encoding: [0x01,0x95,0x0a,0x7e]
$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding -mdis <<< 0x01,0x3f,0x0a,0x7e
        v_tanh_f16_e32 v5, v1                   ; encoding: [0x01,0x3f,0x0a,0x7e]
$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding -mattr=+real-true16 <<< 'v_tanh_bf16 v5.l, v1.l'
        v_tanh_bf16_e32 v5.l, v1.l              ; encoding: [0x01,0x95,0x0a,0x7e]
$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding -mattr=+real-true16 -mdis <<< 0x01,0x95,0x0a,0x7e
        v_tanh_bf16_e32 v5.l, v1.l              ; encoding: [0x01,0x95,0x0a,0x7e]
$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding <<< 'v_tanh_bf16 v5, v1'
        v_tanh_bf16_e32 v5, v1                  ; encoding: [0x01,0x95,0x0a,0x7e]
$ llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding -mdis <<< 0x01,0x95,0x0a,0x7e
        v_tanh_bf16_e32 v5, v1                  ; encoding: [0x01,0x95,0x0a,0x7e]

[rampitec]

Oh, I understand the issue with the tanh, it allows to use fake16 instruction in real-true16 mode.

[rampitec]

But that is the case for any trig operation I have tried:

llvm-mc -arch=amdgcn -mcpu=gfx1200 -show-encoding -mattr=+real-true16 <<< 'v_cos_f16 v5, v1' -debug
Args: /home/stas/work/trunk/bin/bin/llvm-mc -arch=amdgcn -mcpu=gfx1200 -show-encoding -mattr=+real-true16 -debug
AsmMatcher: found 6 encodings with mnemonic 'v_cos_f16'
Trying to match opcode V_COS_F16V_COS_F16_fake16_e32_gfx11
  Matching formal operand class MCK_VGPR_32_Lo128 against actual operand at index 1 (<register v5 mods: abs:0 neg: 0 sext:0>): match success using generic matcher
  Matching formal operand class MCK_VSrcFake16_f16_Lo128 against actual operand at index 2 (<register v1 mods: abs:0 neg: 0 sext:0>): match success using generic matcher
  Matching formal operand class InvalidMatchClass against actual operand at index 3: actual operand index out of range
Missing target features: 175
Trying to match opcode V_COS_F16V_COS_F16_fake16_e32_gfx12
  Matching formal operand class MCK_VGPR_32_Lo128 against actual operand at index 1 (<register v5 mods: abs:0 neg: 0 sext:0>): match success using generic matcher
  Matching formal operand class MCK_VSrcFake16_f16_Lo128 against actual operand at index 2 (<register v1 mods: abs:0 neg: 0 sext:0>): match success using generic matcher
  Matching formal operand class InvalidMatchClass against actual operand at index 3: actual operand index out of range
Opcode result: complete match, selecting this opcode
        v_cos_f16_e32 v5, v1                    ; encoding: [0x01,0xc3,0x0a,0x7e]

[broxigarchen]

llvm-mc -arch=amdgcn -mcpu=gfx1250 -show-encoding -mattr=+real-true16 <<< 'v_tanh_f16 v5.l, v1.l'

This probably just require the test to be updated in true16 syntax. In fact the whole file might need to be updated. I recalled that when this test is created, only the .h test is added and it's stated that this will be updated later

Yeah I think we don't throw error when fake16 format instruction is feed to the assembler in true16 mode

[rampitec]

Every instruction there has at least a line in t16 syntax.

[rampitec]

VOP1 tests update: #161603
Probably all of them need an update.

[rampitec]

VOP3 from VOP1 tests: #161609

[rampitec]

VOP3 tests: #161611