[AMDGPU] Optimize True16 16-bit mov and 16-bit zero

[Sisyph]

On the true16 code generation path, we often see cases where two v_mov_b16 are used, where on the fake16 path one lshlrev/lshrrev is used instead. One v_mov_b16 moves 16 bits from some register to the hi or low half (equivalent to a 16 bit shift) and another v_mov_b16 writes 0 to the other half of that register. We could do this in one instruction lshlrev or lshrrev. Those shift instructions can can do 16-bit data movement and write 0 in the other 16 bits in one instruction. The fake16 path will emit that sequence. We can probably do this with an isel pattern change. See an example here:
#190036 (comment)

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Joe Nash (Sisyph)

Details

On the true16 code generation path, we often see cases where two v_mov_b16 are used, where on the fake16 path one lshlrev/lshrrev is used instead. One v_mov_b16 moves 16 bits from some register to the hi or low half (equivalent to a 16 bit shift) and another v_mov_b16 writes 0 to the other half of that register. We could do this in one instruction lshlrev or lshrrev. Those shift instructions can can do 16-bit data movement and write 0 in the other 16 bits in one instruction. The fake16 path will emit that sequence. We can probably do this with an isel pattern change. See an example here: https://github.com//pull/190036#discussion_r3024404860

[jayfoad]

We can probably do this with an isel pattern change.

This feels like it would need a post-RA peephole, at least to catch the case where the two mov destinations are unrelated but just happen to get allocated to two halves of the same VGPR.

[rampitec]

We can probably do this with an isel pattern change.

This feels like it would need a post-RA peephole, at least to catch the case where the two mov destinations are unrelated but just happen to get allocated to two halves of the same VGPR.

Yeah, but for the case in the testcase there a simple pattern will work.