Project:Toolchain/LTO
This article details the Toolchain project's position on Link Time Optimization.
Rationale
This often gets asked about by users who misunderstand filtering as either not caring or as hostility towards LTO bugs, which is not the case.
The most severe type of bug, in general, is when something compiles successfully but misbehaves at runtime. This brings with it a risk of not just inconveniencing the user, but corrupting data, or affecting the reliability of a system. This may happen silently with no easy way for anyone to notice it.
Some compiler warnings indicate a high chance of software either being miscompiled or likely to be miscompiled in future, either with LTO and/or other optimisations, or different or new compilers. A package hitting these warnings should filter the relevant flags and/or negate them (e.g. strict aliasing which is on by default) if no investigation can be carried out immediately.
A package's test suite passing normally but failing with optimizations is another clear-cut reason to immediately filter.
It's less obvious, but flags like -flto-partition=none or similar are also workarounds and are not acceptable in Gentoo ebuilds: they indicate symbol versioning (or other visibility) is not handled correctly which makes it unsafe. Systems have been left unbootable because of bugs like this in the past: bug #644048, bug #700116.
Plan
Add(done, seefilter-ltotoflag-o-matic.eclasscd9e814fc88a9d2c2ba427fef950cebbae2f6edb)- Trivial glob is a bit messy but also matches stuff like -fno-lto, hence this is needed (e.g. bug #838115)
- Needs to handle non-obvious flags which require LTO (e.g. bug #853280)
- Review blockers of the LTO tracker (bug #618550) and fix appropriately
- Review list of failures from the gentooLTO overlay and fix appropriately
Formulate a policy on USE=lto(done, USE=lto is being phased out in favor oftc-is-ltoandfilter-ltowhere appropriate).- Likely will mean "workarounds are needed in build system" and not "upstream support LTO for this package"
- How can we express the latter though? Many of us would be happy using LTO where we know upstream support it
- See https://marc.info/?l=gentoo-project&m=161957141921902&w=2
Signs a package is unsafe
Some warnings will only appear when building with
-flto which improves diagnostics anyway, but is specifically required for some LTO-related warnings.Build with
-Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing to help catch these issues.- Serious warnings which indicate runtime issues
- Any
-Wodrwarnings - Any
-Wlto-type-mismatchwarnings - Any
-Wstrict-aliasingwarnings
- Any
- Test failures with LTO but passes without
- Failure to build with e.g. multiple LTO partitions
Clang lacks these warnings but the code being unsound still applies to Clang. A compiler not warning on code does not mean it won't optimize based on assumptions around that code. It's just how compilers are written. There are open feature requests to implement these in Clang:
Other distros
- Debian plans to default to LTO either for bookworm or bookworm+1.
- Fedora has defaulted to LTO since Fedora 33 (2021)
- openSUSE defaulted to LTO in 2019