[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