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

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

[Dimitar Dimitrov]

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.

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
-- 
2.31.1

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

[Richard Biener]

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)

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

[Dimitar Dimitrov]

On Mon, Jun 21, 2021 at 08:09:20AM +0200, Richard Biener wrote:
> 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.
> 

Thanks. I added a comment about fat objects being default if ar/nm
plugin is not detected when GCC is configured.  I committed the
following:


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

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.

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 | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/gcc/doc/lto.texi b/gcc/doc/lto.texi
index 1f55216328a..3c5de2144d0 100644
--- a/gcc/doc/lto.texi
+++ b/gcc/doc/lto.texi
@@ -36,11 +36,18 @@ 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
+By default, 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.  For most targets 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, or if no plugin support
+is detected for @code{ar} and @code{nm} when GCC is configured.  It makes
+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 +56,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
-- 
2.31.1