similar to: Issues with DummyCGSCCPass used for IPRA

Hi, There are two relevant hooks for you immutable pass: 1) releaseMemory() 2) doFinalization() Are you looking at the first one? I think you should act on the second instead and it should solve your issue. — Mehdi > On Dec 8, 2016, at 10:58 AM, Maxime Chevalier-Boisvert via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > We have our own subtarget, with its own pipeline

Mehdi, I’m seeing lots of “upgrading” logic, If (UseIPRA) createPass(new DummyCGSCCPass); if (UseIPRA) addPass(createRegUsageInfoPropPass()); if (UseIPRA) addPass(createRegUsageInfoCollector()); ??? --Peter. From: mehdi.amini at

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 :

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 ,

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

Mehdi, I am perusing the 3.8 trunk sources, and don’t find evidence where I would expect it for LLVM “downgrading” a function’s calling convention. PrologEpilogEmitter() { “CodeGen/” ... TFI->determineCalleeSaves() { “Target/XYZ/” TargetFrameLowering::determineCalleeSaves() { “CodeGen/” Return <<< some object derived

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

On Fri, Jul 8, 2016 at 9:47 AM, Lawrence, Peter <c_plawre at qca.qualcomm.com> wrote: > Vivek, > > I am looking into these function attributes in the clang docs > > Preserve_most > > Preserve_all > > They are not available in the 3.6.2 that I am currently using, but I hope > they exist in 3.8 > > > >

Hello Peter, Thanks to pointing out this interesting case. > Vivek, > I have an application where many of the leaf functions are > Hand-coded assembly language, because they use special IO instructions > That only the assembler knows about. These functions typically don't > Use any registers besides the incoming argument registers, IE they don't > Need to

Mehdi, In my mind at least, “whole program” means no dynamic libraries, so the only external functions are simple runtime support, do you have a suggested term for that ? --Peter. From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Tuesday, July 12, 2016 12:31 PM To: Lawrence, Peter <c_plawre at qca.qualcomm.com> Cc: vivek pandya <vivekvpandya at

> On Jul 7, 2016, at 9:17 PM, Lawrence, Peter via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Vivek, > I am looking into these function attributes in the clang docs > Preserve_most > Preserve_all > They are not available in the 3.6.2 that I am currently using, but I hope they exist in 3.8 > > These should provide

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

Hello LLVM Developers, I have a thought to improve IPRA and I would like summaries discussion on IRC regarding that so we can develop an idea out of that if it really helps. So idea is to have more callee saved registers at infrequently called leaf procedures and try provide more registers to procedures which are in upper region of the call graph. But as pointed out by Quentin this optimization

Vivek, Here’s the way I see it, let me know if you agree or disagree, You cannot optimize a function’s calling convention (register-usage) unless You can see and change every caller, and you only know this for non-static functions if you know that all calls to external functions cannot call back into the current compilation unit. #1 gives you the info necessary to change the call-site

Mehdi, I am looking for an understanding of 1) IPRA in general, 2) IPRA in LLVM. Whether I want to use LTO or not is a separate issue. 1) I currently believe it is a true statement that: If all external functions are known to not call back into the “whole-program” Being compiled, then IPRA is free to do anything at all to the functions being

> On Jul 28, 2016, at 12:59 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > 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.

Hello Quentin, I see your work on shrink-wrapping optimization at http://reviews.llvm.org/rL236507 IPRA has benefited shrink-wrapping optimization ( I have noticed that on sqlite3 test-case) so I did read Fred Chow's paper and compare that approach with yours I did not understand much of your work :-( in comparison to original paper but I feel that current approach is not generating same

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

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: > > Hello LLVM Developers, > > I have a thought to improve IPRA and I would like summaries discussion on > IRC regarding that so we can develop an idea out of that if it really helps. > > So idea is

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