[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