Revaulate and enable link-time optimization LTO #12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(This is a medium-term tracker.)
Currently Fedora RISC-V disables LTO for packages by default. This is a trade-off to improve build-times with the hardware we have. See some past discussion here[1].
When the time is right (i.e. when sufficiently fast hardware arrives), we have to re-consider this and enable LTO.
Regardless of the gains we might get from re-enabling LTO, we have to eventually do this anyway to be in sync with primary architectures. Since Fedora 33, LTO is enabled by default[2] in Fedora.
[1] https://discussion.fedoraproject.org/t/fedora-riscv-should-we-disable-lto-gcc-already-disabled-for-clang/96582
[2] https://fedoraproject.org/wiki/LTOByDefault
Note, that we had been building Fedora/RISCV releases with LTO enabled before, but we wanted to speed up things and remove some limitations as LTO is non-mission critical for distro-level functionality. Simply put it doesn't deliver a visible impact to the usage of Fedora/RISCV.
While we do change default flags, we do not touch packages automatically enabling/disabling LTO (or manually by the package maintainers). So it's not really full LTO-off distro-wide.
We also noticed in recent times that packages get less testing with LTO-off, which in some cases are purely bugs. For example it some cases LTO removes all references to a dependency symbol and thus maintainer doesn't list it as a dependency or/and makes sure it doesn't link to it. I do consider that kind of dependency on LTO as a bug in general. These aren't huge numbers, max 10s of these out of 24+K.
I do not consider LTO on/off being a high priority task right now, but it does save us build time.