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: Jan Hubicka <hubicka at ucw dot cz>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Andi Kleen <ak at linux dot intel dot com>, Cary Coutant <ccoutant at google dot com>, Ian Lance Taylor <iant at google dot com>
- Date: Wed, 25 Nov 2015 20:17:40 +0100
- 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> <alpine dot LSU dot 2 dot 11 dot 1511251155460 dot 4884 at t29 dot fhfr dot qr> <CAMe9rOpqi6fM_g1uG2077D+7SrJ5QqBX8mxhPDbah2jQzSpquw at mail dot gmail dot com>
> >
> > Your patch means that Andis/HJs work is no longer needed and we can
> > drop the section suffixes again?
> >
> >
>
> There is a difference between "ld -r " and "gcc -r". "ld -r" may not
> perform any LTO.
Theoretically ld -r may look up for the linker plugin on it search path that will
in turn execute GCC to link the IL. It is not implemented though.
I am not proposing to drop the section based incremental linking code however.
In fact I never paid too much attention to incremental linking. What are the main
use cases? I know some build systems use it to reduce final linking time. What
are the other uses?
It is out of scope of this patch, but eventually it would be nice to teach LTO
optimizers to work incrementally: it is perfectly possible for optimizers to
do their execute methods just not do any decisions that need whole program (i.e.
inlining when size increases) and apply the changes to IL/re-earlyoptimize changed
functions and stream.
Honza
>
> --
> H.J.