[PATCH] D90242: [AMDGPU] Fix check prefix for VOP3 VI disassembler tests

[Dmitry Preobrazhensky via Phabricator via llvm-commits]

dp added inline comments.


================
Comment at: llvm/test/MC/Disassembler/AMDGPU/vop3_vi.txt:300
 
-# CHECK: v_mad_i16 v5, 0.5, v2, v3    ; encoding: [0x05,0x00,0xec,0xd1,0xf0,0x04,0x0e,0x04]
+# VI: v_mad_i16 v5, 0x3800, v2, v3    ; encoding: [0x05,0x00,0xec,0xd1,0xff,0x04,0x0e,0x04]
 0x05,0x00,0xec,0xd1,0xf0,0x04,0x0e,0x04
----------------
rampitec wrote:
> dp wrote:
> > rampitec wrote:
> > > foad wrote:
> > > > The inline constant is disassembled as 0x3800 not 0.5.
> > > > 
> > > > SIMCCodeEmitter does not recognise this constant as an inline 16-bit integer, so the encoding: line shows **0xff** not 0xf0.
> > > > 
> > > > What is the correct behaviour here?
> > > It should be f0.
> > I believe 0xff is an expected result. Change 5f5f566 disabled use of fp inline constants with 16-bit integer operands. When disassembled, these inline constants are deliberately printed in hex to stress that the value is not an inline constant but a literal. 
> > 
> > And yes, the produced dump is incorrect (missing literal) but so is the original code.
> > 
> I would probably say the expected result is an error message if 0.5 cannot really be supported. Isn't it?
I agree, an error message would be helpful, but possibility to disassemble incorrect code is useful as well. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90242