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

Wed Jan 11 23:26:51 PST 2017

Hi Mehdi,

It is true that both IPRA and the proposed mechanism save RegMasks.
So you might say that the data structure in the immutable pass should be reused, but this is the only similarity.

Even this similarity is not exactly true.
I save register masks that doesn’t use passed/returned arguments while IPRA saves register masks for modified registers.
So how can they share the same mechanism?

Regarding immutable pass, I am not familiar with immutable passes that hold correctness information (can you share an example?).

Thanks,
Oren

From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Wednesday, January 11, 2017 20:22
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 11, 2017, at 7:06 AM, Ben Simhon, Oren <oren.ben.simhon at intel.com<mailto:oren.ben.simhon at intel.com>> wrote:

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:

I didn’t know if the implementation would be suited perfectly for your need, but the similarity makes me thing that it is not desirable to have two components doing “almost the same thing” there.

1.      IPRA uses immutable analysis pass called “PhysicalRegisterUsageInfo”. The usage of such passes should be optimization only.
Can you elaborate what makes you say so? Do we a rule that analysis can’t be used to store `correctness` informations?

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.

At this point, I didn’t grasp in what you’re raising above what justify not sharing the infrastructure between IPRA and what you need (again I’m not saying it is ready to do exactly what you need, but I’m against duplicating similar mechanism instead of refactoring).

—
Mehdi

Best Regards,
Oren

From: mehdi.amini at apple.com<mailto: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<mailto:oren.ben.simhon at intel.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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.

---------------------------------------------------------------------
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/20170112/4615f5bf/attachment.html>