similar to: Tail call optimization is getting affected due to local function related optimization with IPRA

According to this http://llvm.org/docs/CodeGenerator.html#tail-call-section, it seems that adding a new CC for the purpose of local function optimization seems a good idea because tail call optimization only takes place when both caller and callee have fastcc or GHC or HiPE calling convention. -Vivek On Sun, Jun 26, 2016 at 1:26 AM, vivek pandya <vivekvpandya at gmail.com> wrote: >

> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > Hello , > > To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: > > bool isEligibleForTailCallOptimization(Function *F) { > CallingConv::ID CC =

Hello , To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: bool isEligibleForTailCallOptimization(Function *F) { CallingConv::ID CC = F->getCallingConv(); if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) return true; return false;

On Sat, Jun 25, 2016 at 11:03 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > Hello LLVM Community, > > To improve Interprocedural Register Allocation (IPRA) we are trying to > force caller > saved registers for local functions (which has likage type local). To > achive it > I have modified TargetFrameLowering::determineCalleeSaves() to return > early for >

On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > Hello , > > To solve this bug locally I have given preference to tail call > optimization over local function related optimization in IPRA. I have added > following method to achieve this: > >

Sent from my iPhone > On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > >> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >>> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: >>> >>> Hello , >>> >>> To solve

On Tue, Jun 21, 2016 at 12:31 AM, Matthias Braun <matze at braunis.de> wrote: > I just discussed this with vivek on IRC (and I think we agreed on this): > > Let me first state the motivation clearly to ease later discussions: > As far as the motivation for this change goes: Changing the calling > convention allows us to choose whether a register is saved by the callee or >

Dear Community, To improve current interprocedural register allocation (IPRA) , we have planned to set callee saved registers to none for local functions, currently I am doing it in following way: if (F->hasLocalLinkage() && !F->hasAddressTaken()) { DEBUG(dbgs() << "Function has LocalLinkage \n"); F->setCallingConv(CallingConv::GHC); } but we think threre

On Tue, Jun 21, 2016 at 8:58 PM, John Criswell <jtcriswel at gmail.com> wrote: > On 6/20/16 11:29 PM, Mehdi Amini wrote: > > > On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: > > Dear Community, > > To improve current interprocedural register

> On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: >> Dear Community, >> >> To improve current interprocedural register allocation (IPRA) , we have planned to set callee saved registers to none for local functions, currently I am doing it in following way:

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);

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

----- 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 >

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

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

Dear community, This is to brief you the progress of Interprocedural Register Allocation, for those who are interested to see the progress in terms of code please consider http://reviews.llvm.org/D20769 This patch contains simple infrastructure to propagate register usage information of callee to caller in call graph. The code generation order is changed to follow bottom up order on call graph ,

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?

Dear Community, The patch for Interprocedural Register Allocation has been committed now , thanks to Mehdi Amini for that. We would like you to play with it and let us know your views and more importantly ideas to improve it. The test-suite run has indicated some non trivial issue that results in run time failure of the programs, we will be investigating it more. Here are some stats :

On Wed, Jun 15, 2016 at 6:16 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Vivek, > > How much of the slow down on runtime comes from the different layout of > the function in the asm file? (I.e., because of the dummy scc pass.) > > Hello Quentin, Please do not consider previous results as there was a major bug in RegMask calculation due to not considering