search for: whopr

Hi, LLVMers, GCC has second approach for LTO, named WHOPR, which can reduce memory usage well. I know LLVM has good LTO and gold plugin support, but it will link Modules into a big one, that causes lots of memory usage while optimization. Did LLVM have any plan on WHOPR or something like that in future? Thanks! -- Best Regards, WenHan Gu (Nowar) -----...

I've been digging into COMDAT with regular LTO, specifically in the context of the LLVM gold plugin. The GCC WHOPR documentation specifies that the linker will resolve all COMDAT groups to the IR-provided definitions, if available. Additionally it specifies that "When the WPA phase produces the definition of the COMDAT symbol in a new object file, that definition should not be in a COMDAT group." (htt...

...ou folks are working on, whenever you're ready to share the details. We will share the details as soon as we can -- possibly some time in Jan 2015. > I read the GCC design docs on LTO, and I'm curious how similar or different your approach will be. For example, the 3-phase approach of WHOPR is fairly sophisticated (it actually follows closely some research done at Rice U. and IBM on scalable interprocedural analysis, in the same group where Preston did his Ph.D.). In Google, we care mostly about peak optimization performance. Peak Optimization is basically PGO + CMO. For cross-module...

On Fri, Dec 12, 2014 at 1:59 PM, Diego Novillo <dnovillo at google.com> wrote: > 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

...2. After all inputs are read linker signals to the plugin to do it's magic. We run LTO and produce one "fat" relocatable object file and feed it back to the linker. Linker finishes it's job as usual. More details of this process are described here: https://gcc.gnu.org/wiki/whopr/driver . If we apply the process described above to our case, we will understand what happened: 1st pass: We see a.o. It is claimed by the plugin. But plugin ignored llvm.exp.f64 intrinsic, so 'exp' symbol was not reported to the linker as referenced symbol. We see static linking of li...

On Wed, Jul 17, 2013 at 1:06 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > > On 7/17/13 12:35 PM, Diego Novillo wrote: >> >> On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> >> wrote: >> >>> 3. How to parallelize post-IPO stage >>> ==================================== >>> >>> From 5k'

...nker signals to the plugin to do it’s magic. > > We run LTO and produce one “fat” relocatable object file and feed it > back to the linker. > > Linker finishes it’s job as usual. > > > > More details of this process are described here: https://gcc.gnu.org/wiki/ > whopr/driver . > > > > If we apply the process described above to our case, we will understand > what happened: > > 1st pass: > > We see a.o. It is claimed by the plugin. But plugin ignored llvm.exp.f64 > intrinsic, so ‘exp’ symbol was not reported to the linker as referen...

On 7/17/13 12:35 PM, Diego Novillo wrote: > On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> 3. How to parallelize post-IPO stage >> ==================================== >> >> From 5k' high, the concept is very simple, just to >> step 1).divide the merged IR into small pieces, >> step 2).and compile