[llvm-dev] How to correctly caller-save return address register

Dominik Montada via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 20 01:15:14 PDT 2021


I actually managed to solve my own problem. If anyone has a similar 
issue in the future, this is what I did:

I marked the return address register as being callee saved in both 
calling conventions. In determineCalleeSaves I then check whether there 
is a function call that uses the new calling convention. If so, I mark 
the return address reg as being required to be spilled. This way I 
basically get a caller-save behavior and can use the already existing 
infrastructure in TargetFrameLowering.

Cheers,

Dominik

On 19.07.21 14:50, Dominik Montada via llvm-dev wrote:
> Hi,
>
> I'm working on a new calling convention for a downstream target. Our 
> target normally saves and restores the return address automatically 
> with the call and return instruction, so there is no need to to handle 
> it in any way. The new calling convention however must save the return 
> address in the caller manually. I thought that the register allocator 
> would spill and restore the register holding the return address around 
> a call, but I guess since we marked the register as reserved, it is 
> not doing that.
>
> I'm wondering now how I should correctly handle this. As a workaround 
> I inserted COPY instructions to and from virtual registers around the 
> call, but although that works, it looks more like a hack instead of a 
> solution.
> Could someone tell me how handling the save and restore of a return 
> address register should look like?
>
> Btw, I tried looking at ARM, but it looks like that LR is marked as 
> callee-saved and therefore handled during prologue/epilogue creation 
> (IIUC). That is not an option for us though.
>
> Cheers,
>
> Dominik
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210720/c973239e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6822 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210720/c973239e/attachment.bin>


More information about the llvm-dev mailing list