On Sun, 20 Jun 2021, Dimitar Dimitrov wrote:
> Slim LTO object files have been the default for quite a while, since:
> commit e9f67e625c2a4225a7169d7220dcb85b6fdd7ca9
> Author: Jan Hubicka <hubi...@gcc.gnu.org>
> common.opt (ffat-lto-objects): Disable by default.
>
> That commit did not update lto.texi, so do it now.
LGTM. Btw, on targets where linker plugin support is not detected
by configury fat objects are still the default.
> gcc/ChangeLog:
>
> * doc/lto.texi (Design Overview): Update that slim objects are
> the default.
>
> Signed-off-by: Dimitar Dimitrov <dimi...@dinux.eu>
> ---
> gcc/doc/lto.texi | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/gcc/doc/lto.texi b/gcc/doc/lto.texi
> index 1f55216328a..755258ccb2b 100644
> --- a/gcc/doc/lto.texi
> +++ b/gcc/doc/lto.texi
> @@ -36,11 +36,16 @@ bytecode representation of GIMPLE that is emitted in
> special sections
> of @code{.o} files. Currently, LTO support is enabled in most
> ELF-based systems, as well as darwin, cygwin and mingw systems.
>
> -Since GIMPLE bytecode is saved alongside final object code, object
> -files generated with LTO support are larger than regular object files.
> -This ``fat'' object format makes it easy to integrate LTO into
> -existing build systems, as one can, for instance, produce archives of
> -the files. Additionally, one might be able to ship one set of fat
> +Object files generated with LTO support contain only GIMPLE bytecode.
> +Such objects are called ``slim'', and they require that tools like
> +@code{ar} and @code{nm} understand symbol tables of LTO sections. These
> tools
> +have been extended to use the plugin infrastructure, so GCC can support
> +``slim'' objects consisting of the intermediate code alone.
> +
> +GIMPLE bytecode could also be saved alongside final object code if the
> +@option{-ffat-lto-objects} option is passed. But this would make the
> +object files generated with LTO support larger than regular object
> +files. This ``fat'' object format allows to ship one set of fat
> objects which could be used both for development and the production of
> optimized builds. A, perhaps surprising, side effect of this feature
> is that any mistake in the toolchain leads to LTO information not
> @@ -49,14 +54,6 @@ This is both an advantage, as the system is more robust,
> and a
> disadvantage, as the user is not informed that the optimization has
> been disabled.
>
> -The current implementation only produces ``fat'' objects, effectively
> -doubling compilation time and increasing file sizes up to 5x the
> -original size. This hides the problem that some tools, such as
> -@code{ar} and @code{nm}, need to understand symbol tables of LTO
> -sections. These tools were extended to use the plugin infrastructure,
> -and with these problems solved, GCC will also support ``slim'' objects
> -consisting of the intermediate code alone.
> -
> At the highest level, LTO splits the compiler in two. The first half
> (the ``writer'') produces a streaming representation of all the
> internal data structures needed to optimize and generate code. This
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
