[LLVMdev] LTO question

Das, Dibyendu Dibyendu.Das at amd.com
Fri Dec 12 18:12:29 PST 2014



Sent from my Windows Phone
________________________________
From: Diego Novillo<mailto:dnovillo at google.com>
Sent: ‎12/‎13/‎2014 3:30 AM
To: Adve, Vikram Sadanand<mailto:vadve at illinois.edu>; <llvmdev at cs.uiuc.edu> List<mailto:llvmdev at cs.uiuc.edu>; Xinliang David Li<mailto:davidxl at google.com>; Teresa Johnson<mailto:tejohnson at google.com>
Subject: Re: [LLVMdev] LTO question

On 12/12/14 15:56, Adve, Vikram Sadanand wrote:
> I've been asked how LTO in LLVM compares to equivalent capabilities
> in GCC.  How do the two compare in terms of scalability?  And
> robustness for large applications?

Neither GCC nor LLVM can handle our (Google) large applications. They're
just too massive for the kind of linking done by LTO.

When we built GCC's LTO, we were trying to address this by creating a
partitioned model, where the analysis phase and the codegen phase are
split to allow working on partial callgraphs
(http://gcc.gnu.org/wiki/LinkTimeOptimization for details).

This allows to split and parallelize the initial bytecode generation and
the final optimization/codegen. However, the analysis is still
implemented as a single process. We found that we cannot even load
summaries, types and symbols in an efficient way.

It does allow for programs like Firefox to be handled. So, if by "big"
you need to handle something of that size, this model can doit.

With LLVM, I can't even load the IR for one of our large programs on a
box with 64Gb of RAM.

> Also, are there any ongoing efforts or plans to improve LTO in LLVM
> in the near future?

Yes. We are going to be investing in this area very soon. David and
Teresa (CC'd) will have details.


Diego.
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141213/878772b3/attachment.html>


More information about the llvm-dev mailing list