Hello,
My impression on *thinLTO* when I first heard of it, (EuroLLVM2015) was
about achieving Cross Module Optimization (CMO) at the IR level.
Having parallel front-end compilation & initial optimization first, a
thin-link of individual input units, more optimization by calling opt again
on the combined IR, and finally the target codegen using llc.
A transformation similar to the following:
Input File 1: Clang+opt (with thinLTO)
Input File 2: Clang+opt (with thinLTO) ---
llvm-link ---- opt (for CMO) --- llc for
target codegen.
…..
Input File n: Clang+opt (with thinLTO)
But from the presentation on LLVM Developers’ Meeting 2016, I believe
thinLTO is more than that. The full advantage of this optimization should
require a significant changes in the backend as well (I suppose).
Before I post my question, kudos to the entire team behind thinLTO
optimization - Teresa Johnson, Mehdi Amni, Xinliang David Li, other
developers and test engineers across the globe.
I am working on the compiler for a target wherein the code size improvement
is a critical factor. We are still using LLVM 3.5 code base. We assume, by
moving to LLVM4.0.0 (with thinLTO and other recent target independent
optimizations) we would be able to improve the codegen to a considerable
number.
With thinLTO in LLVM4.0.0 compiler, when we build an application with
multiple compilation units, is it possible to achieve any benefit purely
with LLVM IR passes (without really involving the compiler backend)?
If yes, can anyone provide me the information about the command-line
options and the sequence to call the llvm components (clang, opt, etc.) to
achieve it.
I truly value any input in this regard.
Regards,
Christu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170712/11659069/attachment.html>
Hi Christu, Thanks for the note! On Wed, Jul 12, 2017 at 9:56 AM, Christudasan D via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello, > > > > My impression on *thinLTO* when I first heard of it, (EuroLLVM2015) was > about achieving Cross Module Optimization (CMO) at the IR level. > > > > Having parallel front-end compilation & initial optimization first, a > thin-link of individual input units, more optimization by calling opt again > on the combined IR, and finally the target codegen using llc. > > > > A transformation similar to the following: > > Input File 1: Clang+opt (with thinLTO) > > Input File 2: Clang+opt (with thinLTO) --- > llvm-link ---- opt (for CMO) --- llc for > target codegen. > > ….. > > Input File n: Clang+opt (with thinLTO) > > > > But from the presentation on LLVM Developers’ Meeting 2016, I believe > thinLTO is more than that. The full advantage of this optimization should > require a significant changes in the backend as well (I suppose). >Right, the model in the EuroLLVM talk was just an initial prototype that used llvm-link/opt, and yes now we do whole program optimizations during the thin link, beyond just linking in additional IR for inlining etc.> > Before I post my question, kudos to the entire team behind thinLTO > optimization - Teresa Johnson, Mehdi Amni, Xinliang David Li, other > developers and test engineers across the globe. > > > > I am working on the compiler for a target wherein the code size > improvement is a critical factor. We are still using LLVM 3.5 code base. We > assume, by moving to LLVM4.0.0 (with thinLTO and other recent target > independent optimizations) we would be able to improve the codegen to a > considerable number. > > > > With thinLTO in LLVM4.0.0 compiler, when we build an application with > multiple compilation units, is it possible to achieve any benefit purely > with LLVM IR passes (without really involving the compiler backend)? > > If yes, can anyone provide me the information about the command-line > options and the sequence to call the llvm components (clang, opt, etc.) to > achieve it. >Do you just want the bitcode out after all optimization passes and before codegen? It is doable with llvm-lto -thinlto-action=run -save-temps I believe (although you will get more bitcode output files than you want, but one of the output bitcode files per input file should be the post-opt pre-codegen bitcode file. The input files to llvm-lto would be bitcode files created by "clang -flto=thin -c -O2 ..." Teresa> > I truly value any input in this regard. > > > > Regards, > > Christu > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170712/34b6b5eb/attachment.html>
On Wed, Jul 12, 2017 at 10:19 AM, Teresa Johnson <tejohnson at google.com> wrote:> Hi Christu, > > Thanks for the note! > > On Wed, Jul 12, 2017 at 9:56 AM, Christudasan D via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello, >> >> >> >> My impression on *thinLTO* when I first heard of it, (EuroLLVM2015) was >> about achieving Cross Module Optimization (CMO) at the IR level. >> >> >> >> Having parallel front-end compilation & initial optimization first, a >> thin-link of individual input units, more optimization by calling opt again >> on the combined IR, and finally the target codegen using llc. >> >> >> >> A transformation similar to the following: >> >> Input File 1: Clang+opt (with thinLTO) >> >> Input File 2: Clang+opt (with thinLTO) --- >> llvm-link ---- opt (for CMO) --- llc for >> target codegen. >> >> ….. >> >> Input File n: Clang+opt (with thinLTO) >> >> >> >> But from the presentation on LLVM Developers’ Meeting 2016, I believe >> thinLTO is more than that. The full advantage of this optimization should >> require a significant changes in the backend as well (I suppose). >> > > Right, the model in the EuroLLVM talk was just an initial prototype that > used llvm-link/opt, and yes now we do whole program optimizations during > the thin link, beyond just linking in additional IR for inlining etc. > > >> >> Before I post my question, kudos to the entire team behind thinLTO >> optimization - Teresa Johnson, Mehdi Amni, Xinliang David Li, other >> developers and test engineers across the globe. >> >> >> >> I am working on the compiler for a target wherein the code size >> improvement is a critical factor. We are still using LLVM 3.5 code base. We >> assume, by moving to LLVM4.0.0 (with thinLTO and other recent target >> independent optimizations) we would be able to improve the codegen to a >> considerable number. >> >> >> >> With thinLTO in LLVM4.0.0 compiler, when we build an application with >> multiple compilation units, is it possible to achieve any benefit purely >> with LLVM IR passes (without really involving the compiler backend)? >> >> If yes, can anyone provide me the information about the command-line >> options and the sequence to call the llvm components (clang, opt, etc.) to >> achieve it. >> > > Do you just want the bitcode out after all optimization passes and before > codegen? It is doable with llvm-lto -thinlto-action=run -save-temps >Sorry, that last option should be -thinlto-save-temps=foo, where "foo" will be the prefix of the generate temp files (can include a path). You want the foo*.opt.bc files for the output of the opt pipeline in the backends. I believe (although you will get more bitcode output files than you want,> but one of the output bitcode files per input file should be the post-opt > pre-codegen bitcode file. The input files to llvm-lto would be bitcode > files created by "clang -flto=thin -c -O2 ..." > > Teresa > > >> >> I truly value any input in this regard. >> >> >> >> Regards, >> >> Christu >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | > 408-460-2413 <(408)%20460-2413> >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170712/d7879561/attachment.html>