similar to: RFC: Dynamically Allocated "Callee Saved Registers" Lists

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

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?

Hi Mehdi, I think that the subject of the RFC is misleading. The true problem that we are trying to solve is to remove returned/passed arguments from the regmask (According to the calling convention). IPRA and CC updated RegMask can’t use the same mechanism because they contradict each other. I think that the following analog will help to explain why I think that a reuse is redundant: Let’s

Here in an example that explains the difference. // Only declaration – No implementation // Assume that the value is returned in EAX and the arguments are passed in EAX, ECX, EDX, ESI, EDI. int __regcall callee (int a, int b, int c, int d, int e); // implemented in a different module void caller() { … x = callee(1,2,3,4,5); … } What will be RegMask using IPRA register usage collector? Callee

Hi All, The Register Calling Convention (RegCall) was introduced by Intel to optimize parameter transfer on function call. This calling convention ensures that as many values as possible are passed or returned in registers. To use RegCall, place the keyword before a function declaration. For example: __regcall int foo (int i, int j); // Windows OS __attribute__((regcall)) foo (int I, int j); //

Hi, I want to add Target Specific MachineFunctionPass so that it will run during Link Time Optimization. The pass is currently running in non-LTO compilation (added in addPreEmitPass). What do I need to do in order to run my pass also during LTO? Thanks, Oren --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may

Adding Support For Vectorcall Calling Convention ===================================================== Vectorcall Calling Convention for x64 ---------------------------------------------------- The __vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible. __vectorcall uses more registers for arguments than __fastcall or the default x64

Hi Jakob, On Thu, Oct 4, 2012 at 2:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 4, 2012, at 2:27 PM, "Madhusudan C.S" <madhusudancs at gmail.com> > wrote: > > Basically, the PrologEpilogInsertion pass will add a bit mask to >> MachineModuleInfo describing which registers are clobbered by the function >> being compiled. Later,

Hello Mentors, I did analyze assembly files generated for IPRA + PGO. (1) I observed that I did not considered the scope of the optimization so changing callee saved register set for non local function is bad because IPRA can not pass this information to other modules. (2) applying this change to indirect function also has no effect because for such case IPRA is currently not able to propagate

The code in X86TargetLowering::IsEligibleForTailCallOptimization() has this part: // The callee has to preserve all registers the caller needs to preserve. const X86RegisterInfo *TRI = Subtarget.getRegisterInfo(); const uint32_t *CallerPreserved = TRI->getCallPreservedMask(MF, CallerCC); if (!CCMatch) { const uint32_t *CalleePreserved = TRI->getCallPreservedMask(MF, CalleeCC);

----- Original Message ----- > From: "vivek pandya" <vivekvpandya at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Quentin Colombet" > <qcolombet at apple.com>, "Mehdi Amini" <mehdi.amini at apple.com> > Sent: Friday, July 29, 2016 5:02:44 AM >

Dear R-help, Can some one tell me how to do the following (if it's possible)? Suppose I have a function like this: f <- function(x, y, ...) { ## some code g(x, y, ...) ## some more code } The problem is that g() may not understand everything that comes through in "...". Is there a way to delete some component of "..." and then pass it to g()? Here's

Hello Mentors, I am currently finding bug in Local Function related optimization due to which runtime failures are observed in some test cases, as those test cases are containing very large function with recursion and object oriented code so I am not able to find a pattern which is causing failure. So I tried following simple case to understand expected behavior from this optimization. Consider

On Fri, Jul 29, 2016 at 9:01 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "vivek pandya" <vivekvpandya at gmail.com> > > To: "Mehdi Amini" <mehdi.amini at apple.com> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Hal Finkel" <hfinkel at anl.gov>, > "Quentin

On Wed, Feb 8, 2017 at 6:21 PM, Wei Mi <wmi at google.com> wrote: > I have an issue that I've been wrestling with for quite some time and I'm > hoping that someone with a deeper understanding of the register allocator > can help me with. > > Namely, I am trying to teach RA to split a live range rather than > allocating a CSR. I've attempted a very large number

On Sat, Jul 9, 2016 at 12:18 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jul 8, 2016, at 11:41 AM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > > On Fri, Jul 8, 2016 at 11:46 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Jul 8, 2016, at 11:12 AM, vivek pandya <vivekvpandya at gmail.com> wrote:

Vivek, IIUC it seems that we need two pieces of information to do IPRA, 1. what registers the callee clobbers 2. what the callee does to the call-graph And it is #2 that we are missing when we define an external function, Even when we declare it with a preserves or a regmask attribute, So what I / we need is another attribute that says this is a leaf function, At least in my case all

Dear Community, Please find summary of work done during this week as follow: Implementation: ============ During this week we have identified a bug in IPRA due to not considering RegMask of function calls in given machine function. The same bug on AArch64 has been reported by Chad Rosier and more detailed description can be found at https://llvm.org/bugs/show_bug.cgi?id=28144 . To fix this bug

I have been working on PGO driven IPRA and I want to measure if this help to reduce execution time. So as mentioned earlier the idea is to make cold function register usage free i.e saving and restoring all used register by such cold function so caller of that function will have more free registers. So here I am changing standard callee saved registers set to a set which will be decided

Hello Clang and LLVM Devs, I have been working to add support for an attribute in clang and LLVM that helps user to guide interprocedural register allocation. But the use case I am having is very limited and thus I belieave it is good to have discussion on this before sending a patch. So for IPRA we have a situation where a function is calling a function which is written in assembly and it is