RFC: Help with updating LTO documentation

RFC: Help with updating LTO documentation

[Steve Ellcey]

While trying to use the -flto and -fwhole-program flags I ran into problems
understanding what they do.  I would like to update the documentation but I
still don't understand these flags enough to be able to describe their
behaviour.  Here is the document section I would like to fix but don't
have enough information to do so.

From lto.texi:

| @subsection LTO modes of operation
| 
| One of the main goals of the GCC link-time infrastructure was to allow
| effective compilation of large programs.  For this reason GCC implements two
| link-time compilation modes.
| 
| @enumerate
| @item   @emph{LTO mode}, in which the whole program is read into the
| compiler at link-time and optimized in a similar way as if it
| were a single source-level compilation unit.
| 
| @item   @emph{WHOPR or partitioned mode}, designed to utilize multiple
| CPUs and/or a distributed compilation environment to quickly link
| large applications.  WHOPR stands for WHOle Program optimizeR (not to
| be confused with the semantics of @option{-fwhole-program}).  It
| partitions the aggregated callgraph from many different @code{.o}
| files and distributes the compilation of the sub-graphs to different
| CPUs.

What flag(s) do I use (or not use) to enable @emph{LTO mode}?
I am guessing that if I use -flto but not -flto-partition on a
link, this is what I get.  Is that correct?

What flag(s) do I use to enable @emph{WHOPR or partitioned mode}?
I am guessing that this is -flto-partition?  Do I also need -flto if I
am using -flto-partition?  I don't see any description in lto.texi or in
common.opt of exactly what the various values for -flto-partition
(none, one, balanced, 1to1, max) do.  Does such a description exist
anywhere?

Steve Ellcey
sellcey@marvell.com

Re: RFC: Help with updating LTO documentation

[Richard Biener]

On Wed, Aug 7, 2019 at 6:33 PM Steve Ellcey <sellcey@marvell.com> wrote:
>
> While trying to use the -flto and -fwhole-program flags I ran into problems
> understanding what they do.  I would like to update the documentation but I
> still don't understand these flags enough to be able to describe their
> behaviour.  Here is the document section I would like to fix but don't
> have enough information to do so.
>
> From lto.texi:
>
> | @subsection LTO modes of operation
> |
> | One of the main goals of the GCC link-time infrastructure was to allow
> | effective compilation of large programs.  For this reason GCC implements two
> | link-time compilation modes.
> |
> | @enumerate
> | @item   @emph{LTO mode}, in which the whole program is read into the
> | compiler at link-time and optimized in a similar way as if it
> | were a single source-level compilation unit.
> |
> | @item   @emph{WHOPR or partitioned mode}, designed to utilize multiple
> | CPUs and/or a distributed compilation environment to quickly link
> | large applications.  WHOPR stands for WHOle Program optimizeR (not to
> | be confused with the semantics of @option{-fwhole-program}).  It
> | partitions the aggregated callgraph from many different @code{.o}
> | files and distributes the compilation of the sub-graphs to different
> | CPUs.
>
> What flag(s) do I use (or not use) to enable @emph{LTO mode}?
> I am guessing that if I use -flto but not -flto-partition on a
> link, this is what I get.  Is that correct?
>
> What flag(s) do I use to enable @emph{WHOPR or partitioned mode}?
> I am guessing that this is -flto-partition?  Do I also need -flto if I
> am using -flto-partition?  I don't see any description in lto.texi or in
> common.opt of exactly what the various values for -flto-partition
> (none, one, balanced, 1to1, max) do.  Does such a description exist
> anywhere?

"LTO mode" is merely legacy and can be invoked with
-flto -flto-partition=none while "WHOPR mode" is the default
and is used with plain -flto.  Both modes use a linker-plugin
(if available) to enable "whole program" mode (aka auto-detection
of -fwhole-program).  Not using a linker-plugin is legacy as well.

Richard.

> Steve Ellcey
> sellcey@marvell.com