llvm dev - Jan 2017 - RFC: Dynamically Allocated "Callee Saved Registers" Lists

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170109/32df2c10/attachment.html>

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>

On Mon, Jan 09, 2017 at 12:47:07PM +0300, Bruce Hoult via llvm-dev
wrote:
> Is there any calling convention, on any supported platform, that requires
> the callee to preserve a register that was used to pass an argument?
The "this" parameter for constructors and possible other things is
handled like that on some platforms. ARM EABI I think?

Joerg

> On Jan 9, 2017, at 1:09 AM, 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.
Have you looked at how IPRA is implemented? It needs to dynamically allocate the
register mask as well, so unless there is something fundamentally different I’m
missing, we should share the mechanism.

— 
Mehdi


>  
> 
> 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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/cdbeb53a/attachment-0001.html>

Thanks Bruce for your comments.

Unfortunately there are calling conventions that require a callee to preserve a
register that was used for argument passing.
For example: hhvm (passes and preserves R12), swift (passes and preserves R12
& R13).

Apparently there are other calling conventions that can use the proposed
solution.
For example: Interrupt handler CC that needs to preserve all registers (instead
of passed/returned arguments).

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

Your solution is the approach I started with while updating around 50 places
were “fnCalleeSavedRegs” is calculated, but I encountered several issues:

1.      Creating “fnArgs” every time is expensive because it requires calling
the CC functions every time.

2.      So “fnArgs” is bitmap that needs to be created and stored somewhere.

3.      Not in every place that we use “archCSR” we have (or can calculate)
fnArgs because in some cases we don’t have the Machine Function handler.

Basically, my proposed solution is: Instead of calculating “fnArgs” and
“fnCalleeSavesRegs” every time – Calculate “fnCalleeSavesRegs” once and save it.

Thanks again,
Oren

From: bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] On Behalf Of
Bruce Hoult
Sent: Monday, January 09, 2017 11:47
To: Ben Simhon, Oren <oren.ben.simhon at intel.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] RFC: Dynamically Allocated "Callee Saved
Registers" Lists

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<mailto: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<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

---------------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170109/1c6bf199/attachment.html>

Hi Mehdi,

I wasn’t familiar with IPRA before, thank you for bringing it up.
After studying it, I have to say that IPRA is a wonderful idea and is well
implemented.

I tried to reuse the mechanism for the last couple of days.
I implemented a solution using IPRA mechanism and encountered few issues:

1.      IPRA uses immutable analysis pass called “PhysicalRegisterUsageInfo”.
The usage of such passes should be optimization only. In my case, this is a
functional issue. The analysis must run in order to be compatible with other
compilers.

2.      IPRA passes are not enabled by default and when they are enabled many
tests fail due to various reasons (mainly because the CallGraph bottom up
approach).

3.      The manipulated RegMasks generated using RegUsageInfoCollector are very
different than the manipulated RegMasks that I need. It will be an abuse to
change the current pass implementation. So new pass is required.

4.      When dumping the MIR after running IPRA passes, assertion is raised
because the RegMask name is unknown (same issue that I face with my solution –
see “open Issue”).
I might reuse the analysis pass of IPRA instead of saving the RegMask inside the
Machine Function but as mentioned by #1 it is not recommended.
Thus I believe that using my current suggestion is more suitable for the issue I
am resolving.

Best Regards,
Oren

From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Monday, January 09, 2017 18:38
To: Ben Simhon, Oren <oren.ben.simhon at intel.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] RFC: Dynamically Allocated "Callee Saved
Registers" Lists


On Jan 9, 2017, at 1:09 AM, Ben Simhon, Oren via llvm-dev <llvm-dev at
lists.llvm.org<mailto: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.

Have you looked at how IPRA is implemented? It needs to dynamically allocate the
register mask as well, so unless there is something fundamentally different I’m
missing, we should share the mechanism.

—
Mehdi







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<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

---------------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170111/a8d6a474/attachment.html>