[llvm-dev] Can we get interprocedural register allocation work across module boundary?

vivek pandya via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 5 20:28:21 PDT 2016


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>


More information about the llvm-dev mailing list