[llvm-dev] RFC: Dynamically Allocated "Callee Saved Registers" Lists

[Bruce Hoult via llvm-dev]

Weird calling convention, but I see that's as documented at e.g.

https://software.intel.com/en-us/node/522787

Silly question:

Is there any calling convention, on any supported platform, that requires
the callee to preserve a register that was used to pass an argument?

Of course someone *could* define such a CC, but if there isn't currently
one, then we don't need to support that possibility *yet*.

If no one has done that then no need to add a whole new special case just
for IA32 __regcall. We could just for every function do something like
(assuming a bitmap representation):

fnCalleeSavedRegs = archCSR & ~fnArgs
fnScratchRegs = ~fnCalleeSavedRegs & ~archSpecialRegs; // if not included
in CSR

This is simple enough to be calculated whenever it's needed, not stored.


On Mon, Jan 9, 2017 at 12:09 PM, Ben Simhon, Oren via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Dynamically Allocated “Callee Saved Registers” Lists
>
>
>
> Each Calling convention (CC) defines a static list of registers that
> should be preserved by a callee function. All other registers should be
> saved by the caller.
>
> Some CCs use additional condition: If the register is used for
> passing/returning arguments – the caller needs to save it - even if it is
> part of the Callee Saved Registers (CSR) list.
>
> For example consider the following function:
>
> *void __regcall func(int a, int b, int c, int d, int e);*
>
> According to RegCall CC, parameters *d* and *e* should reside in
> registers EDI and ESI. The problem is that these registers also appear in
> the CSR list of RegCall calling convention. So, since the registers were
> used to pass arguments the callee doesn’t have to preserve their values.
>
> The current LLVM implementation doesn’t support it. It will save a
> register if it is part of the static CSR list and will not care if the
> register is passed/returned by the callee.
>
>
>
> There are two types of static CSR lists:
>
> 1.      register mask array of the CSRs (including register aliases)
>
> 2.      register CSR list
>
>
>
> The proposed solution is to dynamically allocate the CSR lists (Only for
> these CCs). The lists will be updated with actual registers that should be
> saved by the callee.
>
>
>
> Since we need the allocated lists to live as long as the function exists,
> the list should reside inside the Machine Register Info (MRI) which is a
> property of the Machine Function and managed by it (and has the same life
> span).
>
>
>
> The lists should be saved in the MRI and populated upon LowerCall and
> LowerFormalArguments.
>
>
> Open Issue
>
>
>
> Machine Instructions (MI) have intermediate representation that can be
> printed and later on parsed to recreate the MIs.
>
> MI printer and parser expect the Register Mask array pointer to point to a
> predefined (static) list of RegMasks. Those lists are retrieved from auto
> generated file x86GenRegisterInfo.inc using the functions: getRegMasks()
> and getRegMaskNames().
>
> However, since we create a dynamically allocated register mask, its
> pointer will not reside in the static lists and no corresponding name could
> be found.
>
> In that case, the MIPrinter will fail to emit the RegMask Name.
>
>
>
> I would appreciate the community opinion regarding my solution and
> regarding possible solutions to the open issue.
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20170109/6916d7fd/attachment.html>