[PATCH] D144271: [AMDGPU][MC] Enable modifiers on V_MOV_B32

[Joe Nash via Phabricator via llvm-commits]

Joe_Nash added a comment.

In D144271#4140757 <https://reviews.llvm.org/D144271#4140757>, @foad wrote:

> In D144271#4139988 <https://reviews.llvm.org/D144271#4139988>, @Joe_Nash wrote:
>
>> In D144271#4139981 <https://reviews.llvm.org/D144271#4139981>, @arsenm wrote:
>>
>>> In D144271#4139979 <https://reviews.llvm.org/D144271#4139979>, @Joe_Nash wrote:
>>>
>>>> Actually, I think due to the way the operand lists for _e32 instructions are constructed, the modifiers are not taking effect.
>>>> If you dump the tablegen records, if the change was effective there should be a src0_modifiers operand on the V_MOV_B32_e32 instruction.
>>>
>>> I'd expect it to only be on v_mov_b32_e64?
>>
>> I guess the spec was changed between gfx9 and gfx10. On gfx10 and newer the docs say modifiers are supported on VOP1 as well as VOP3. But in terms of what our backend would make with just the above patch, it seems the modifiers would be on v_mov_b32_e64 but not v_mov_b32_e32. Hence my ask to check the tablegen records.
>
> There are no modifiers in VOP1 - there are no bits in the encoding for them.

Ah yes, that makes a lot more sense. Sorry, I was not thinking clearly there. 
The intention of this patch seems ok then to allow the modifiers on v_mov_b32_e64. Since modifiers are not supported on gfx9 and earlier, it would likely need the introduction of a new pseudo instruction for v_mov_b32, one for gfx10Plus that allows modifiers on VOP3.

But we make limited use of v_mov_b32_e64. So should more work be done to make use of it?
The potential utility is to do something like v_mov_b32 v0, -v1. But in a lot of cases this could be folded into the use of v0 by setting the neg modifier there.


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

https://reviews.llvm.org/D144271