[PATCH] D14327: IR: Add llvm.ldexp and llvm.experimental.constrained.ldexp intrinsics

Joe Nash via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 7 07:00:53 PDT 2023


Joe_Nash added inline comments.


================
Comment at: llvm/test/MC/Disassembler/AMDGPU/gfx10_vop3.txt:7523
 
-# GFX10: v_ldexp_f16_e64 v5, v1, -4.0            ; encoding: [0x05,0x00,0x3b,0xd5,0x01,0xef,0x01,0x00]
+# GFX10: v_ldexp_f16_e64 v5, v1, 0xc400          ; encoding: [0x05,0x00,0x3b,0xd5,0x01,0xff,0x01,0x00,0x00,0xc4,0x00,0x00]
 0x05,0x00,0x3b,0xd5,0x01,0xef,0x01,0x00
----------------
arsenm wrote:
> foad wrote:
> > What caused this change in the assembler/disassembler behaviour? It looks like it has broken round-tripping, since the "encoding" output is longer than the input.
> The exp operand was incorrectly marked as i32 when it's really i16. The inline immediate values are then different
I believe that operand should be f16. We still want to be able to assemble inline fp constants. From a semantic point of view, these are i16 constants, but from an encoding point of view they are f16. 
In the True16 support downstream I have been treating that argument as f16. If you want it to be i16 yet still support inline fp constants, we need to effectively revert 5f5f566b265db00f577ead268400d99f34ba9cdd


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

https://reviews.llvm.org/D14327



More information about the llvm-commits mailing list