[PATCH] D127527: [AMDGPU] Define SGPR_NULL64 register. NFCI.

Joe Nash via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 14 06:10:28 PDT 2022


Joe_Nash added a comment.

In D127527#3579963 <https://reviews.llvm.org/D127527#3579963>, @rampitec wrote:

> In D127527#3579878 <https://reviews.llvm.org/D127527#3579878>, @rampitec wrote:
>
>> In D127527#3579759 <https://reviews.llvm.org/D127527#3579759>, @rampitec wrote:
>>
>>> In D127527#3579552 <https://reviews.llvm.org/D127527#3579552>, @Joe_Nash wrote:
>>>
>>>> LGTM, but could there be more opportunities to use this? 
>>>> Are there cases where we want to have value 0 in a source operand (a normal VSrc, not VOPDstS64orS32 like is used in https://reviews.llvm.org/D127542), it can't be folded, and we could use sgpr null 64? It might be interesting to have a test case for that with folding excluded.
>>>
>>> 0 is inline literal, so usually we can use inline 0 instead.
>>
>> I can see one marginal case where a 64 bit add/sub is expanded and we are unable to shrink the first instruction so produce V_ADD_CO_CI_U32/V_SUB_CO_CI_U32, e.g. add or sub with an SGPR operand. Here null can be used as a carry-in.
>
> And even this case is impractical. On gfx10 we can use 2 constants, so addc with a vgpr and sgpr will fall down to be shrunk and use vcc as a carry-in, and an operation with 2 sgprs will be SALU.

Ok, thanks! It seems we have many ways to optimize instructions with zero operands, so the use of the null sgpr is quite specific.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127527



More information about the llvm-commits mailing list