[FFmpeg-devel] [PATCH] configure: add LTO optarg

[alice]

On Thu Mar 23, 2023 at 3:16 PM CET, J. Dekker wrote:
> On 23 Mar 2023, at 14:56, Martin Storsjö wrote:
> >>     test "$cc_type" != "$ld_type" && die "LTO requires same compiler and linker"
> >> -    check_cflags  -flto
> >> -    check_ldflags -flto $cpuflags
> >> +    check_cflags  -flto=$lto
> >> +    check_ldflags -flto=$lto $cpuflags
> >
> > Does GCC support -flto=full too, and is that the same thing as just -flto? Or should we stick to just passing -flto to the compiler without any argument if the user configured with plain --enable-lto?
>
> No, actually checking it. We might benefit from gcc's -ffat-lto-objects and/or -fwhole-program which is maybe more similar to LLVM's -flto=full. Seems like there is non-trivial mapping between LTO features.

-ffat-lto-objects is only about keeping non-lto object code as well as the
intermediate (lto) code in the .o objects.

this is 'required' if one wants to then later link the resulting .a's *without*
using lto, as having only the 'intermediate' output forces using lto during the
link step.

by default for gcc, the only difference between -flto and -flto=[n]/auto is the
amount of threads used during linking. =auto is generally preferred, since under
the gnu make jobserver it controls the jobs instead (or defaults to nproc). the
existing `-flto` forces 1-thread link under gcc, and it prints a warning for
this:

 lto-wrapper: warning: using serial compilation of 12 LTRANS jobs
 lto-wrapper: note: see the '-flto' option documentation for more information

(the gcc(1) manpage documents this quite well.)

however, i'd say the existing behaviour here is fine. there are indeed a lot of
toolchain-specifics between all this- and people building that care about this
would usually know better than a 'magic' configure script that tries to learn
all of it. simply respecting -flto[=arg] with a user-supplied arg is all that is
generally needed.

as for -fwhole-program, i'm not sure it has any use:

 With -flto this option has a limited use. In most cases the precise list of
 symbols used or exported from the binary is known the resolution info passed to
 the link-time optimizer by the linker plugin. It is still useful if no linker
 plugin is used or during incremental link step when final code is produced (with
 -flto -flinker-output=nolto-rel).

(by default, the linker plugin is automatically used for modern-ish gcc (since
maybe 4.9?))