[PATCH] D114652: [AMDGPU] Treat call clobbered return address registers s[30:31] as callee saved

Sebastian Neubauer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 30 00:01:25 PST 2021


sebastian-ne added inline comments.


================
Comment at: llvm/test/CodeGen/AMDGPU/gfx-callable-return-types.ll:26-48
+; GFX9-NEXT:    s_or_saveexec_b64 s[34:35], -1
+; GFX9-NEXT:    buffer_store_dword v1, off, s[0:3], s32 ; 4-byte Folded Spill
+; GFX9-NEXT:    s_mov_b64 exec, s[34:35]
+; GFX9-NEXT:    v_writelane_b32 v1, s33, 2
+; GFX9-NEXT:    s_mov_b32 s33, s32
+; GFX9-NEXT:    s_addk_i32 s32, 0x400
+; GFX9-NEXT:    s_getpc_b64 s[34:35]
----------------
scott.linder wrote:
> RamNalamothu wrote:
> > sebastian-ne wrote:
> > > This codes gets quite a bit worse. But I’m not sure if we can do anything about it.
> > > This codes gets quite a bit worse. But I’m not sure if we can do anything about it.
> > 
> > Yeah. This is a known scenario where previously the s[30:31] were being spilled to another SGPR pair, which was used to return, but now since the return address should always be in s[30:31] it has to be spilled into either VGPR or memory.
> > 
> > For now, we will have to live with it.
> > 
> > May be we could do something during SGPRSpillLowering to use the available SGPRs, not only for this case but in general?
> > I didn't check if that capability is already in place and s[30:31] is a corner case which is not handled.
> I'm not sure I understand how the old code is correct to begin with; does it rely on knowledge about the called function?
> 
> I think in a "fixed function ABI" world we can't just clobber (in this example) `s[36:37]`, right?
As you said, it relies on knowledge about the called function.
The IPRA (Inter Procedural Register Allocation) pass looks at direct callees and removes registers from the call-clobbered list if the called function does not touch them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114652



More information about the llvm-commits mailing list