[llvm] [WIP][AMDGPU] Split `isInlinableLiteral16` into three and call the specific version if possible (PR #81345)

Stanislav Mekhanoshin via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 23 13:53:14 PST 2024


================
@@ -99,39 +99,39 @@ define i32 @inline_A_constraint_H1() {
 ; VI-LABEL: {{^}}inline_A_constraint_H2:
 ; VI: v_mov_b32 {{v[0-9]+}}, 0x3c00
 define i32 @inline_A_constraint_H2() {
-  %v0 = tail call i32 asm "v_mov_b32 $0, $1", "=v,A"(i16 bitcast (half 1.0 to i16))
+  %v0 = tail call i32 asm "v_mov_b32 $0, $1", "=v,A"(trunc i32 bitcast (float 1.0 to i32) to i16)
----------------
rampitec wrote:

If you drop 'A' from the equation things get easy. This is 0x3c00 regardless of the instruction context. When you finally assemble it you see this cannot be inline and just use literal. But that is how our asm and inline asm work in general. `v_mov_b32 {{v[0-9]+}}, 0x3c00` is a right thing to me... if we just drop 'A'. And this right thing also tells nothing about the encoding too, the test just does not check the encoding. Check this:

```
llvm-mc -arch=amdgcn -mcpu=gfx1100 -show-encoding <<< 'v_add_f16 v0, v1, 0x3c00'
        v_add_f16_e64 v0, v1, 1.0               ; encoding: [0x00,0x00,0x32,0xd5,0x01,0xe5,0x01,0x00]
```
I have used 0x3c00, but the inline 1.0 was encoded as a shortest form. Regardless of how I wrote it in the asm.

```
llvm-mc -arch=amdgcn -mcpu=gfx1100 -show-encoding <<< 'v_add_f16 v0, v1, 0x3c01'
        v_add_f16_e64 v0, v1, 0x3c01            ; encoding: [0x00,0x00,0x32,0xd5,0x01,0xff,0x01,0x00,0x01,0x3c,0x00,0x00]
```
This does not fit and it is literal.

So when we are handling inline asm we just do not deal with the encoding at all, and printing 0x3c00 does not tell anything about the encoding, nor it tests it.

IMHO the proper fix shall drop the word 'inline' from the documentation.

https://github.com/llvm/llvm-project/pull/81345


More information about the llvm-commits mailing list