AMDGPU inreg arguments for SGPRs use whole VGPRs after SGPR arguments run out

[arsenm]

When SGPR available for argument passing run out, they silently switch to using whole VGPRs to pass arguments.

; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx950 -o - %s

target triple = "amdgcn-amd-amdhsa"

define i32 @test0(<8 x i32> inreg %arg0,
                  <8 x i32> inreg %arg1,
                  <2 x i32> inreg %arg2,
                  i32 inreg %arg3,
                  i32 inreg %arg4) {
  %add = add i32 %arg3, %arg4 ; arg3 is v0, arg4 is in v1. These should be packed into a lane and extracted with readlane
  ret i32 %add
}

Ideally we would start to pack inreg arguments into individual lanes of VGPRs, not directly into VGPRs.

In this example, we ran out of SGPRs after 18 arguments. %arg3 and %arg4 end up in v0 and v1. We could treat these as WWM values, and pass them in v0.lane0 and v0.lane1.

Either way, we should get a scalar value in downstream code rather than forced VALU usage

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Matt Arsenault (arsenm)

When SGPR available for argument passing run out, they silently switch to using whole VGPRs to pass arguments.

; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx950 -o - %s

target triple = "amdgcn-amd-amdhsa"

define i32 @<!-- -->test0(&lt;8 x i32&gt; inreg %arg0,
                  &lt;8 x i32&gt; inreg %arg1,
                  &lt;2 x i32&gt; inreg %arg2,
                  i32 inreg %arg3,
                  i32 inreg %arg4) {
  %add = add i32 %arg3, %arg4 ; arg3 is v0, arg4 is in v1. These should be packed into a lane and extracted with readlane
  ret i32 %add
}

Ideally we would start to pack inreg arguments into individual lanes of VGPRs, not directly into VGPRs.

In this example, we ran out of SGPRs after 18 arguments. %arg3 and %arg4 end up in v0 and v1. We could treat these as WWM values, and pass them in v0.lane0 and v0.lane1.

Either way, we should get a scalar value in downstream code rather than forced VALU usage

[shiltian]

We should see a crash at the moment. I'll fix it after #113782 is fixed by #127353.

[shiltian]

And then we have illegal COPY generated after #127353 was landed, as reported by #130443. Will need to fix #130443 first.