[llvm] [AMDGPU] Add lit() asm operand modifier for SP3 compatibility. (PR #68839)

Stanislav Mekhanoshin via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 12 00:04:23 PDT 2023


rampitec wrote:

> > This does not force literal encoding for an inline immediate, but neither does SP3. The syntax is dummy for compatibility only.
> 
> Thanks. This sounds OK to me. Really we should go one better than SP3 and force literal encoding, but I guess that is hard to implement.

Yes, it needs:

1) Extra bit in the MCOperand. This should be a per-operand state.
2) More logic in the constant bus checks.

This could be theoretically added later, but not required for compatibility.

> Do you think the disassembler should emit lit(), either for all literal operands or at least for ones that could have been encoded as inlines?

Unless we enforce literal encoding I do not see a reason to clutter the output.

> Does your implementation accept `lit(abs(123.0))`? Does SP3 accept that?

This does not support it:
```
llvm-mc -arch=amdgcn -mcpu=tonga -show-encoding  <<< 'v_sqrt_f32 v2, lit(abs(123.0))'
	.text
<stdin>:1:20: error: failed parsing operand.
v_sqrt_f32 v2, lit(abs(123.0))
                   ^
```
SP3 does, although there is no abs modifier used anyway. It might be possible to support, but I see no usecases. On practice people just use lit(<number>). Actually since SP3 does not do it I see no way to check if HW even supports modifier bits with literals. So far lit() is just a sort of syntax glue.

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


More information about the llvm-commits mailing list