Incremental LTO linking part 2: lto-plugin support

Jan Hubicka hubicka@ucw.cz
Wed May 9 08:55:00 GMT 2018


> On Tue, 8 May 2018, Jan Hubicka wrote:
> 
> > > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > > > Hi,
> > > > with lto, incremental linking can be meaninfuly done in three ways:
> > > >  1) read LTO file and produce non-LTO .o file
> > > >     this is current behaviour of gcc -r or ld -r with plugin
> > > >  2) read LTO files and merge section for later LTO
> > > >     this is current behaviour of ld -r w/o plugin
> > > >  3) read LTO files into the compiler, link them and produce
> > > >     incrementaly linked LTO object.
> > > >
> > > > 3 makes most sense and I am maing it new default for gcc -r. For testing purposes
> > > > and perhaps in order to have tool to turn LTO object into real object, we want
> > > > to have 1) available as well.  GCC currently have -flinker-output option that
> > > > decides between modes that is decided by linker plugin and can be overwritten
> > > > by user (I have forgot to document this).
> > > >
> > > > I am targeting for -flinker-output=rel to be incremental linking into LTO
> > > > and adding -flinker-output=nolto-rel for 1).
> > > >
> > > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO
> > > > object files theger.  For 2 HJ's binutils patchset has support and I think
> > > > it can be extended to handle 3 as well. But with default binutils we want
> > > > to warn users.  This patch implements the warning (and prevents linker plugin
> > > > to add redundat linker-ouptut options.
> > > 
> > > 
> > > My users/hjl/lto-mixed/master branch is quite flexible.  I can extend
> > > it if needed.
> > 
> > I think once the main patchset settles down we could add a way to communicate
> > to lto-plugin if combined lto+non-lto .o files are supported by linker and sillence
> > the warning.
> 
> How does the patchset deal with partially linking fat objects?  How

Currently it will turn them into slim LTO merged object. I can add code path
that will optimize them into binary. That will be additional fun because we probably
want to WPA them, but it should not be that hard to implement: WPA will produce one
object file with merged LTO data that will be passed to linker plus partitions that will
be turned to final binary.

> do HJs binutils deal with them when you consider a fat object partially
> linked with a non-LTO object?

HJ?
Honza
> 
> Richard.
> 
> -- 
> Richard Biener <rguenther@suse.de>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)



More information about the Gcc-patches mailing list