This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Incremental LTO linking part 2: lto-plugin support
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Cary Coutant <ccoutant at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 9 May 2018 10:14:26 +0200 (CEST)
- Subject: Re: Incremental LTO linking part 2: lto-plugin support
- References: <20180508151413.GB16916@kam.mff.cuni.cz> <CAMe9rOrVMW+0aScjJ9GYBfdaNmYmm5ufY6nk=noH3WEMOFwbAQ@mail.gmail.com> <20180508210123.GS90955@kam.mff.cuni.cz>
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
do HJs binutils deal with them when you consider a fat object partially
linked with a non-LTO object?
Richard.
--
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)