similar to: Can we get interprocedural register allocation work across module boundary?

On Tue, Jul 5, 2016 at 11:54 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Jul 5, 2016, at 9:28 AM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > > Hello Mentors, > > > > I have a very naive idea to get IPRA woking at link time and thus > extending its scope to intermodule. I seek some help if it seems to be a > feasible

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

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

Hello LLVM Developers, Please feel free to send any ideas that you can think to improve current IPRA. I will work on it and if possible I will implement that. Please consider summary of work done during this week. Implementation: ============ The reviews requests has been updated to reflect the reviews. Testing: ===== To get more benefit from IPRA I experimented it with LTO and results

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

Dear Community, Sorry for being late for weekly status report but I was traveling back to my college. Please consider this week's summary as follows: Implementation: ============ This week I tried to get experimental PGO driven IPRA work. The idea is to save all register in prolog and restore it in epilog for cold function so that IPRA can propagate some free register to upper region of

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

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

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 :

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

Mehdi, I’m compiling embedded applications which are small enough to do whole-program-compilation. There’s no advantage in breaking them up into separate compilation pieces and linking them, even though in source form they are composed of a couple of separate source files. So for me the compilation unit is always the entire program (and includes main()) Except for some

Hello LLVM Developers, Please follow summary of work done during this week. Implementation: ============ During this week patch for bug fix 28144 is updated after finding more refinement in remarks calculation. As per suggestion from Matthias Braun and Hal Finkel regmask calculation code is same as MachineRegisterInfo::isPhysRegModified() except no check of isNoReturnDef() is required. So we

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

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 ,

Vivek, I apologize if you took my original email as a request for implementation, I meant to be asking what is already available, I think the answer to that is the ‘preserves_most’ and ‘preserves_all’ attributes, but I will also Use ‘regmask’ if those prove to be too sub-optimal. I am still interested in figuring out the necessary and sufficient conditions For LLC to do optimal IPRA

On Mon, Jun 20, 2016 at 12:54 AM, vivek pandya <vivekvpandya at gmail.com> wrote: > Dear Professor, > > Thanks to bring this to notice, I tried out a simple test case with > indirect function call: > > int foo() { > return 12; > } > > int bar(int a) { > return foo() + a; > } > > int (*fp)() = 0; > int (*fp1)(int) = 0; > > int main() { >

On Mon, Jun 20, 2016 at 4:14 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Vivek, > > [Dropping firefox-dev, since I don't want to spam them] > > vivek pandya via llvm-dev wrote: > > Measure W/O IPRAWITH IPRA > > ======================== > > Total Build Time76 mins82.3 mins8% increment > > Octane v2.0 JS Benchmark Score (higher is

Hello, I build FireFox-46.0.1 source with llvm to test interprocedural register allocation. The build was successful with out any runtime faliures, here are few stats: Measure W/O IPRA WITH IPRA ======= ======== ========= Total Build Time 76 mins 82.3 mins 8% increment Octane v2.0 JS Benchmark Score (higher is better) 18675.69 19665.16 5% improvement Kraken JS Benchmark time (lower is better)

On Tue, Jun 21, 2016 at 1:45 AM, Matthias Braun <matze at braunis.de> wrote: > > > On Jun 20, 2016, at 12:53 PM, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi Vivek, > > > > vivek pandya via llvm-dev wrote: > > > int foo() { > > > return 12; > > > } > > > > > >