Comments

From: Andi Kleen <ak@linux.intel.com>
This adds a new LTO mode "lto slim" that only puts LTO information
into the object file, no "fallback code". This improves compilation
performance because the code has to be only generated once. It also
allows some future extensions I am planning to do.
The disadvantage is that a slim build requires more tool chain support
because there is no "safety net" of fallback code in the object file.
For example ar and ranlib need use the gcc lto plugin (and currently
need to be binutils mainline) to be able to create the symbol indexes.
Also libtool needs to be updated. And it will only work with
the linker plugin.
Because of these complications slim LTO is not default, but a separate
-flto-slim option. The option works with whopr and with LTO.
Spreading the checking of the flag into the various frontends is ugly,
but I didn't find a simple nicer way to do this.
Thanks to Jan Hubicka for some fixes to my initial version.
Requires earlier patches to fix up collect2.
This passes normal bootstrap and testing.
gcc/ada/
2010-10-11 Andi Kleen <ak@linux.intel.com>
* utils.c (gnat_write_global_declarations): Bail out early
when flag_lto_slim is set.
gcc/
2010-10-11 Andi Kleen <ak@linux.intel.com>
Jan Hubicka <jh@suse.cz>
* cgrapunit.c (ipa_passes): Check for flag_lto_slim.
(cgraph_optimize): Bail out early if flag_lto_slim is set.
* common.opt (flto-slim): Add.
* doc/invoke.texi (-flto-slim): Document.
* langhooks.c (write_global_declarations): Check for
flag_lto_slim.
* toplev.c (compile_file): Check for flag_lto_slim.
gcc/cp
2010-10-11 Andi Kleen <ak@linux.intel.com>
* decl2.c (cp_write_global_declarations): Check for
flag_lto_slim.
gcc/lto
2010-10-11 Andi Kleen <ak@linux.intel.com>
* lto.c (lto_main): Set flag_lto_slim to zero.
---
gcc/ada/gcc-interface/utils.c | 3 +++
gcc/cgraphunit.c | 13 ++++++++++++-
gcc/common.opt | 5 +++++
gcc/cp/decl2.c | 8 +++++---
gcc/doc/invoke.texi | 10 +++++++++-
gcc/langhooks.c | 7 +++++--
gcc/lto/lto.c | 3 +++
gcc/toplev.c | 7 +++++--
8 files changed, 47 insertions(+), 9 deletions(-)

On 10-10-16 11:09 , Andi Kleen wrote:
> +@item -flto-slim> +Only generate LTO output, no assembler. The result is that the assembler> +code is only generated once for a LTO build. This flag is ignored for the LTO> +frontend. Will only work with the @option{-fuse-linker-plugin} and> +with the @command{gold} linker.
s/Will only/This option will only/
The patch looks fine, but the option is currently not tested. Could you
add it to LTO_OPTIONS in testsuite/lib/lto.exp:lto_init ?
Diego.

On Tue, Nov 2, 2010 at 12:01 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 10-10-16 11:09 , Andi Kleen wrote:>>> +@item -flto-slim>> +Only generate LTO output, no assembler. The result is that the assembler>> +code is only generated once for a LTO build. This flag is ignored for the>> LTO>> +frontend. Will only work with the @option{-fuse-linker-plugin} and>> +with the @command{gold} linker.>> s/Will only/This option will only/>> The patch looks fine, but the option is currently not tested. Could you add> it to LTO_OPTIONS in testsuite/lib/lto.exp:lto_init ?
Hm, it won't work without the linker plugin, will it? So it's not that easy.
Richard.
>> Diego.>

On Tue, Nov 2, 2010 at 07:05, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 12:01 PM, Diego Novillo <dnovillo@google.com> wrote:>> On 10-10-16 11:09 , Andi Kleen wrote:>>>>> +@item -flto-slim>>> +Only generate LTO output, no assembler. The result is that the assembler>>> +code is only generated once for a LTO build. This flag is ignored for the>>> LTO>>> +frontend. Will only work with the @option{-fuse-linker-plugin} and>>> +with the @command{gold} linker.>>>> s/Will only/This option will only/>>>> The patch looks fine, but the option is currently not tested. Could you add>> it to LTO_OPTIONS in testsuite/lib/lto.exp:lto_init ?>> Hm, it won't work without the linker plugin, will it? So it's not that easy.
Oh, yeah. We'd need to wait for the linker plugin to be built unconditionally.
Diego.

> Oh, yeah. We'd need to wait for the linker plugin to be built unconditionally.
There's that.
FWIW -- i currently use a private LTO test suite because I found it difficult
to express many of the multi file test cases I have in dejagnu. It simply
uses Makefiles.
I realize it's not a very satisfying situation.
-Andi

On Tue, Nov 2, 2010 at 12:42 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> Oh, yeah. We'd need to wait for the linker plugin to be built unconditionally.>> There's that.>> FWIW -- i currently use a private LTO test suite because I found it difficult> to express many of the multi file test cases I have in dejagnu. It simply> uses Makefiles.>> I realize it's not a very satisfying situation.
;)
I guess it wouldn't be too hard to detect a $testcase.mk file and
invoke that with 'build' 'run' and 'clean' rules from dejagnu. At least
it wasn't too hard to add linker-plugin support or suppor for multi-language
tests. For a non-TCL speaker, that is ;)
Richard.
> -Andi>