[all-commits] [llvm/llvm-project] 4cee5c: [AMDGPU] Free reserved VGPR if no SGPR spill

[Ruiling, Song via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4cee5cad28fd9b4d04075223746bfbb642dd1937
      https://github.com/llvm/llvm-project/commit/4cee5cad28fd9b4d04075223746bfbb642dd1937
  Author: Ruiling Song <ruiling.song at amd.com>
  Date:   2021-03-12 (Fri, 12 Mar 2021)

  Changed paths:
    M llvm/lib/Target/AMDGPU/SILowerSGPRSpills.cpp

  Log Message:
  -----------
  [AMDGPU] Free reserved VGPR if no SGPR spill

I met some code generation behavior change when I tried to remove
the hasStackObject() check when reserving VGPR for SGPR spill.
For example, the function `callee_no_stack_no_fp_elim_all` in the lit
test file `callee-frame-setup.ll`.
The generated code changed from:
```
  s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
  s_mov_b32 s4, s33
  s_mov_b32 s33, s32
  s_mov_b32 s33, s4
  s_setpc_b64 s[30:31]
```

into something like:
```
  s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
  v_writelane_b32 v63, s33, 0
  s_mov_b32 s33, s32
  v_readlane_b32 s33, v63, 0
  s_setpc_b64 s[30:31]
```

I think we still prefer the old version where only scalar instructions are needed.
The idea here is free the reserved VGPR if no SGPR spills. So we will very likely
to use a free SGPR for fp/sp spill.

Reviewed by: arsenm

Differential Revision: https://reviews.llvm.org/D98344


  Commit: e8e6817d00a4dd1ba563a96aec2fd2be8f35dea9
      https://github.com/llvm/llvm-project/commit/e8e6817d00a4dd1ba563a96aec2fd2be8f35dea9
  Author: Ruiling Song <ruiling.song at amd.com>
  Date:   2021-03-12 (Fri, 12 Mar 2021)

  Changed paths:
    M llvm/lib/Target/AMDGPU/SIISelLowering.cpp
    M llvm/test/CodeGen/AMDGPU/reserve-vgpr-for-sgpr-spill.ll

  Log Message:
  -----------
  [AMDGPU] Don't check hasStackObjects() when reserving VGPR

We have amdgpu_gfx functions that have high register pressure. If
we do not reserve VGPR for SGPR spill, we will fall into the path
to spill the SGPR to memory, which does not only have correctness issue,
but also have really bad performance.

I don't know why there is the check for hasStackObjects(), in our case,
we don't have stack objects at the time of finalizeLowering(). So just
remove the check that we always reserve a VGPR for possible SGPR spill
in non-entry functions.

Reviewed by: arsenm

Differential Revision: https://reviews.llvm.org/D98345


Compare: https://github.com/llvm/llvm-project/compare/6708186c91dd...e8e6817d00a4