llvm dev - Jul 2016 - 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 idea.
> >
> > So idea is to take advantage of LTO's capability to work with bit
code
> files. LTO can optimize number of bitcode files and combine them into a big
> module. LTO then generates native code for the big module.
>
> Yes, that’s how LTO works.
>
> >
> > So does it seem feasible to have clang generates bit code files for
the
> source code and then combine then with LTO and LTOCodeGenerater will use
> current IPRA infrastructure, so IPRA will be improved as now it can
> propagate actual regmask for procedures define in other modules (not
> system/external library calls).  If this is possible then one problem I can
> sense is requirement of huge memory to hold a big module for large
projects.
>
> I don’t understand what you describe, or how it changes from LTO how it
> works right now.
>
> IPRA, how we implemented it, is a simple “codegen option” that can be
> enabled during LTO.
>
Ok I got your point. So using IPRA during LTO is a way to get most benefit
out of IPRA but h\this will incur some overheads due to LTO. I think it
would be better to try this experiment with a small application to provide
a good example of this.
-Vivek
> I think at some point at the beginning of the project, you mentioned some
> paper about IPRA during link-time and we told you that it was not relevant
> for LLVM because of the way LTO works: IPRA can be enabled transparently
> during LTO.
>
> —
> Mehdi
>
>
> >
> > If this idea seems feasible please help me to shape a concrete work
plan
> on this.
> >
> > Sincerely,
> > Vivek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160706/07eb76ba/attachment.html>

On Wed, Jul 6, 2016 at 8:58 AM, vivek pandya <vivekvpandya at gmail.com>
wrote:
>
>
> 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 idea.
>> >
>> > So idea is to take advantage of LTO's capability to work with
bit code
>> files. LTO can optimize number of bitcode files and combine them into a
big
>> module. LTO then generates native code for the big module.
>>
>> Yes, that’s how LTO works.
>>
>> >
>> > So does it seem feasible to have clang generates bit code files
for the
>> source code and then combine then with LTO and LTOCodeGenerater will
use
>> current IPRA infrastructure, so IPRA will be improved as now it can
>> propagate actual regmask for procedures define in other modules (not
>> system/external library calls).  If this is possible then one problem I
can
>> sense is requirement of huge memory to hold a big module for large
projects.
>>
>> I don’t understand what you describe, or how it changes from LTO how it
>> works right now.
>>
>> IPRA, how we implemented it, is a simple “codegen option” that can be
>> enabled during LTO.
>>
> Ok I got your point. So using IPRA during LTO is a way to get most benefit
> out of IPRA but h\this will incur some overheads due to LTO. I think it
> would be better to try this experiment with a small application to provide
> a good example of this.
> -Vivek
>
I tried to use IPRA with -flto option like  -flto  -mllvm -enable-ipra
-mllvm -debug-only=ip-regalloc but it seems that while lto is enabled code
generator does not enable IPRA. because I don't get any debug information.
Or Am I missing any options related to LTO here ?

-Vivek
>
>
>> I think at some point at the beginning of the project, you mentioned
some
>> paper about IPRA during link-time and we told you that it was not
relevant
>> for LLVM because of the way LTO works: IPRA can be enabled
transparently
>> during LTO.
>>
>> —
>> Mehdi
>>
>>
>> >
>> > If this idea seems feasible please help me to shape a concrete
work
>> plan on this.
>> >
>> > Sincerely,
>> > Vivek
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160707/d4d02a44/attachment.html>

> On Jul 6, 2016, at 9:39 PM, vivek pandya <vivekvpandya at gmail.com
<mailto:vivekvpandya at gmail.com>> wrote:
> 
> 
> 
> On Wed, Jul 6, 2016 at 8:58 AM, vivek pandya <vivekvpandya at gmail.com
<mailto:vivekvpandya at gmail.com>> wrote:
> 
> 
> On Tue, Jul 5, 2016 at 11:54 PM, Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
> 
> > On Jul 5, 2016, at 9:28 AM, vivek pandya <vivekvpandya at gmail.com
<mailto: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 idea.
> >
> > So idea is to take advantage of LTO's capability to work with bit
code files. LTO can optimize number of bitcode files and combine them into a big
module. LTO then generates native code for the big module.
> 
> Yes, that’s how LTO works.
> 
> >
> > So does it seem feasible to have clang generates bit code files for
the source code and then combine then with LTO and LTOCodeGenerater will use
current IPRA infrastructure, so IPRA will be improved as now it can propagate
actual regmask for procedures define in other modules (not system/external
library calls).  If this is possible then one problem I can sense is requirement
of huge memory to hold a big module for large projects.
> 
> I don’t understand what you describe, or how it changes from LTO how it
works right now.
> 
> IPRA, how we implemented it, is a simple “codegen option” that can be
enabled during LTO.
> Ok I got your point. So using IPRA during LTO is a way to get most benefit
out of IPRA but h\this will incur some overheads due to LTO. I think it would be
better to try this experiment with a small application to provide a good example
of this.
> -Vivek
> I tried to use IPRA with -flto option like  -flto  -mllvm -enable-ipra
-mllvm -debug-only=ip-regalloc but it seems that while lto is enabled code
generator does not enable IPRA. because I don't get any debug information.
Or Am I missing any options related to LTO here ?
You have to understand that there are two phases: compile to .o (bitcode when
-flto is supplied) and linking.
The linking phase is actually when the code generator runs, so you need to pass
the option to LLVM through the linker.
On OS X the linker will accept -mllvm options, but when you invoke the link
phase through clang you have to use -Wl,  to pass the option to the linker.


— 
Mehdi
> 
> -Vivek
>  
> I think at some point at the beginning of the project, you mentioned some
paper about IPRA during link-time and we told you that it was not relevant for
LLVM because of the way LTO works: IPRA can be enabled transparently during LTO.
> 
> —
> Mehdi
> 
> 
> >
> > If this idea seems feasible please help me to shape a concrete work
plan on this.
> >
> > Sincerely,
> > Vivek
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160706/ebfcec60/attachment-0001.html>