This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Getting LTO incremental linking work
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Andi Kleen <ak at linux dot intel dot com>, gcc-patches at gcc dot gnu dot org, hongjiu dot lu at intel dot com, ccoutant at google dot com, iant at google dot com
- Date: Thu, 26 Nov 2015 11:22:56 +0100 (CET)
- Subject: Re: [RFC] Getting LTO incremental linking work
- Authentication-results: sourceware.org; auth=none
- References: <20151125085912 dot GD58491 at kam dot mff dot cuni dot cz> <20151125235858 dot GI8438 at tassilo dot jf dot intel dot com> <20151126003828 dot GH20593 at kam dot mff dot cuni dot cz>
On Thu, 26 Nov 2015, Jan Hubicka wrote:
> > > Moreover we do have all infrastructure ready to implement 3). Our tree merging
> > > and symbol table handling is fuly incremental and I think made a patch to
> > > implement it today. The scheme is easy:
> >
> > What happens when .S (assembler) files are part of the incremential object?
> > The kernel does that. Your patch would do the final generation in this case,
> > right?
>
> Yes, it will spit out warning (which can be silenced -Wl,-rnolto is used) and turn
> the whole object into non-LTO one.
> >
> > In theory we could change the build system to avoid that case though, but
> > it would need some changes.
> >
> > It would be better if that could be handled somehow.
The final output of the incremental link would need to be two objects,
one with the LTO IL and one with the incrementally linked non-LTO
objects. The only way to make it "one" object is a static archive?
Or extend ELF to behave as a "container" for multiple sub-objects...
> How does this work with your patchset? Ideally we should have way to claim
> only portions of object files, but we don't have that. If we claim the file,
> the symbols in real symbol table are not visible.
>
> I suppose we could play a games here with slim LTO: claim the file, see if
> there are any symbols defined in the non-LTO symbol table and if so, interpret
> read the symbol table and tell linker about the symbols and at the very end
> include the offending object file in the list of objects returned back to
> linker.
This is what I was trying with early-LTO-debug btw... the slim object
also contains early debug sections which I don't "claim" and I feed
the objects back to the linker (as plugin output), expecting it to
drop the LTO IL and take the early debug sections...
> The linker then should take the symbols it wants. There would be some fun
> involved, because the resolution info we get will consider the symbols
> defined in that object file to be IR which would need to be compensated for.
A sensible option might be to simply error on incrementally linking
slim-LTO with non-LTO objects. For fat objects we could either
drop LTO or error as well.
Fixing this on the user (Makefile) side would be easiest. But it
has to use two incrementally linked objects in this case of course
so it wouldn't be very transparent.
Richard.