RFC: enable link time optimization

Fedora, SUSE or the Firefox builds provided by Mozilla use LTO by default and the numbers look promising. LTO aims to produce smaller and faster binaries.

I suggest to try LTO as a default for Alpine.

Further reading:

• https://fedoraproject.org/wiki/LTOByDefault
• https://www.ucw.cz/~hubicka/slides/opensuse2018-e.pdf
• https://hubicka.blogspot.com/2016/03/building-libreoffice-with-gcc-6-and-lto.html#more
• https://glandium.org/blog/?p=3888
• https://wiki.ubuntu.com/ToolChain/LTO

Makes sense, meson has -Db_lto

changed the description

mentioned in merge request !101 (closed)

@kaniini any doubts pairing this with the upcoming GCC 11 upgrade?

For LDC: https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html

Given that GCC 11 isn’t likely to happen until at least GCC 11.2, it seems like a reasonable timeline to do both at the same time. But I expect GCC 11 to be an Alpine 3.16 thing.

GCC 11.2 has been merged in aports@c29fc976

BOLT for clang/llvm looks promising too

mentioned in merge request aports!27971 (closed)

is there anything potentially blocking this now that gcc 11.2 is the edge compiler? some packages do prefer --enable-lto or equivalents in their configure scripts for some extra checking aside from just a simple -flto in global flags, but i think we can give it a try.
also not sure if the gcc issue in !101 (closed) still exists, but i expect it to need some extra flag, e.g. per gentoo toolchain --with-build-config=bootstrap-lto in https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/toolchain.eclass that is used in the gcc ebuild

ah, just --enable-lto for gcc seems to be fine

This should also be considered for other compilers, e.g. RUSTFLAGS for rustc

rustflags do not work for this- a [profile.release] with lto = true or = "thin" (what we already do) works differently to setting global flags for every rustc invocation. the majority of things cannot compile with RUSTFLAGS -C lto=true or somesuch

What about RUSTC_OPT_LEVEL?

I’ve been building rust packages with LTO enabled since the beginning (example). However, I need to test a better way to set these flags globally instead of patching Cargo.toml.

CARGO_PROFILE_RELEASE_LTO=true should do the work, but I have to test it.

I have used CC=clang CXX=clang++ RUSTFLAGS="-Clinker=clang -Ctarget-cpu=native -Clink-arg=-fuse-ld=lld -Clinker-plugin-lto" CARGO_PROFILE_RELEASE_LTO=thin for Rust packages on Gentoo for a couple months now. It seems to work for most packages, including firefox, spidermonkey, and librsvg. Compiling Rust itself requires unsetting CARGO_PROFILE_RELEASE_LTO and removing -Clinker-plugin-lto because rustc uses non-c dylibs which is not compatible with LTO. This applies to all non-c dylibs, but there shouldn't be that many of those in distro.

What are the benefits of CC=clang CXX=clang++ RUSTFLAGS="-Clinker=clang -Ctarget-cpu=native -Clink-arg=-fuse-ld=lld -Clinker-plugin-lto"?

-Ctarget-cpu=native is self-explanatory, -Clinker-plugin-lto allows cross-language LTO (mainly useful for firefox), CC=clang CXX=clang++ RUSTFLAGS=-Clinker=clang is required for that. see https://doc.rust-lang.org/rustc/linker-plugin-lto.html. i think -Clink-arg=-fuse-ld=lld is not technically necessary anymore since bfd also supports "LLVMgold.so" but according to https://llvm.org/docs/GoldPlugin.html this is "not officially supported or recommended". -Clink-arg=-fuse-ld=lld also significantly improves link speed and memory usage though.

maybe this is better suited in https://gitlab.alpinelinux.org/alpine/tsc/?

probably, yes

mentioned in issue tsc#37 (closed)

mentioned in merge request !135 (merged)

was rejected in tsc#37 (closed), we do this per-package opt-in instead

closed