[PATCH] D134423: [AMDGPU] Fix vgpr2sgpr copy analysis to check scalar operands of buffer instructions use scalar registers.

[krishna chaitanya sankisa via Phabricator via llvm-commits]

skc7 added a comment.

In D134423#3896343 <https://reviews.llvm.org/D134423#3896343>, @alex-t wrote:

> Sorry for my tediousness but
> I would like to see any inspirational reason for this change.
>
> The change in the LIT test suggests one - we get rid of the waterfall loop, but I would like to see (if possible) a simpler case and verbal description regarding "why do we need this?"
> It is a good idea just because not any SGPR use requires such special processing but the 128-bit SGPR in MUBUF instruction is legalized by creating the waterfall loop which affects performance.  So, the justification here is necessary.
>
> I also would like to see the test case where the VGPR to SGPR copy result has multiple uses.
> It would be useful to check what happens if there are multiple VGPR uses besides the one that requires SGPR.
>
> In general, the approach now looks like an attempt to hack into the concrete input pattern.
>
> Although, I don't know other cases which add a significant penalty for moveToVALU.  We should think of some unified per-opcode penalty interface if we have more cases.

  %8:sreg_32 = COPY %5:vgpr_32
  %7:vgpr_32 = BUFFER_LOAD_DWORD_OFFEN %4:vgpr_32, killed %6:sgpr_128, %8:sreg_32, 0, 0, 0, 0, implicit $exec ::

si-fix-sgpr-copies pass converts this as below

  %7:vgpr_32 = BUFFER_LOAD_DWORD_OFFEN %4:vgpr_32, killed %6:sgpr_128, %5:vgpr_32, 0, 0, 0, 0, implicit $exec :: (dereferenceable load (s32), align 1, addrspace 4)

soffset which is supposed to be scalar register has been converted to use vgpr. This is failing in the backend with error "Illegal virtual register for instruction".

With this patch I'm trying to fix this issue by checking that scalar registers are used for soffset and srsrc of MUBUF/MTBUF.


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

https://reviews.llvm.org/D134423