[PATCH] D91048: [AMDGPU] Add new pseudos for indirect addressing with VGPR Indexing

Austin Kerbow via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 9 19:39:14 PST 2020


kerbowa added a comment.

In D91048#2383872 <https://reviews.llvm.org/D91048#2383872>, @rampitec wrote:

> In D91048#2383678 <https://reviews.llvm.org/D91048#2383678>, @kerbowa wrote:
>
>> In D91048#2383420 <https://reviews.llvm.org/D91048#2383420>, @rampitec wrote:
>>
>>> Is there a practical reason to have different pseudos for set_idx and movrel methods and not just expand a common pseudo accordingly post RA?
>>
>> It's a good question but in the end, I chose not to since m0 initializations can be rescheduled, and combing the pseudo's would disallow this. The other issue is that the movrel pseudo includes the scalar version which is used on targets with VGPR indexing as well. I'm open to trying it if you think it seems more practical.
>
> Both methods use M0, aren't they?

Yes, but the GPR_IDX method also sets the mode at the same time and cannot be rescheduled unlike a simple write to m0.

> The scalar version might be an argument, but I guess it is just a matter of selecting an indirect move for scalar version based on the the subtarget or not.

The s_movrel is expanded from INDIRECT_REG_WRITE_MOVREL_pseudo for subtargets with and without gpr indexing. The VGPR indexing only effects the vector variants where what matters is whether we are changing the mode register or not. Since this method sets m0 and the mode at the same time the pseudo instruction takes an extra sgpr operand. The v_movrel version emits the write to m0 earlier, and so this pseduo does not need the extra operand unless we combine the pseudos and are delaying emitting the m0 write until later than we currently do. My thought was that since the m0 write in the movrel version can be rescheduled it should be expanded earlier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91048



More information about the llvm-commits mailing list