[PATCH] doc/lto.texi: List slim object format as the default

Richard Biener rguenther@suse.de
Mon Jun 21 06:09:20 GMT 2021


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 <hubicka@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 <dimitar@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 <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)


More information about the Gcc-patches mailing list