LTOByDefault

LTO by default for package builds

Summary

This is a proposal to enable link time optimization (LTO) of packages by default. LTO, in general, produces smaller and faster executables. LTO also allows for deeper compile-time analysis of code to find defects such as uninitialized variables/memory, buffer overflows, etc.

Owner

• Name: law
• Email: law@redhat.com

Current status

• Targeted release: Fedora 32
• Last updated: 2019-11-11
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Packages will be built with LTO by default to produce smaller and faster executables/DSOs. The LTO bytecode itself will not be distributed as it is not stable from one GCC release to the next.

There will be an opt-out mechanism for packages that need it. Goal is opt-out would be a single variable set in the package's .spec file.

Benefit to Fedora

The primary benefits of building with LTO enabled are smaller, faster executables/DSOs. A secondary benefit is LTO allows deeper analysis of package source code at compile time which can improve various GCC diagnostics and thus improve our ability to catch bugs at compile time.

Scope

• Proposal owners:

The primary change is to redhat-rpm-config to add LTO to the default compile/link flags as well as a conditional which allows easy opt-out on a package by package basis. Additionally the post-build scripts need to strip the LTO bytecodes from any installed .o/.a files.

There will be packages that need to opt-out. For example, LTO is known not to work with linker scripts that provide symbol versioning within a DSO. More interestingly, some packages will fail to build with LTO due to improved compile time analysis for diagnostics. Finally some packages are known to use horribly out of date configure scripts which can be compromised by LTO optimizations. I'm happy to work with the package owners to address these issues.

It's an isolated change in redhat-rpm-config and its post-processing scripts. However, the change affects everything within the distribution that is compiled with GCC. We have some prototype work already done for the redhat-rpm-config changes and the SuSE engineers have post-processing scripts to strip out the LTO bytecode at install time that we can use.

• Other developers:

As I mentioned, I'm happy to contact package owners that need to modify their packages and suggest how their package needs to be fixed. It would be advantageous if I could get proven packager privileges to address the simplest of these issues.

We already know there are some issues with configure scripts generated by old versions of autoconf. When possible those scripts would be rebuilt with modern versions of autoconf. That may not be possible in all circumstances -- for these exceptional cases I believe the existing scripts can be fixed with a relatively simple sed script we could insert into a package's .spec file.

I have a means by which I can continuously test Fedora builds with this feature enabled so that we can address issues proactively rather than late in the Fedora 32 release cycle. All the work would need to land prior to the mass rebuild in Jan/Feb.

We know there are some problems with debugging LTO optimized code. We will be working with the GDB team to identify these issues and fix them either in the debugger or compiler as needed.

• Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)

Aside from the redhat-rpm-config changes, I do not expect any work from releng to be necessary. However, they need to be aware of the change and who to contact in case of issues.

• Policies and guidelines:

It would be useful to document how to opt-out of LTO in the packaging guidelines

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Should not affect compatibility. Stripping of the LTO bytecode is critical to ensure there are not long term compatibility issues.

How To Test

In the short term, I'm happy to expose a repository with a gcc-10 snapshot and updated redhat-rpm-config. Developers could then use that repo to pick up gcc-10 and LTO optimizations for testing purposes. I'm already doing this internally for x86_64 and exposing it to the world would be trivial.

Given such a repository, another developer would merely use that repo when building their package. No special hardware is needed. The most useful testing is first to identify FTBFS issues and get them proactively fixed. I'm happy to own that since I'm already doing that for the gcc-10 effort, testing LTO at the same time is a natural extension.

Doing the same testing on other architectures would definitely be useful. I'd be particularly concerned about large packages on the 32bit architectures. I wouldn't be surprised if we find some packages need to opt-out of LTO because they run out of memory at link/compile time. I'm already in contact with some Debian maintainers who want to do testing around this issue as they're investigating a similar change for Debian.

User Experience

In theory, the only noticeable difference to users would be smaller, faster binaries and DSOs. However, a developer that uses rpmbuild to build their own code may see their package fail to build if it's got errors or uses certain features that do not work with LTO.

Users who try to debug Fedora executables could notice differences in the debugging experience.

Dependencies

None expected beyond addressing FTBFS issues and coordination between GCC and GDB teams on any debugging issues we find during our testing of LTO + debugging over the next 6-8 weeks.

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? No
• Blocks product? No

In the event a show stopping issue was found with LTO we could just revert the relevant redhat-rpm-config change which would disable the LTO flags by default. It is more likely that some packages have bugs that are exposed by LTO that we may not be able to get the package owners to fix in time for Fedora 32. For those packages the contingency plan would be to have those specific packages opt-out of LTO.

Documentation

I would think we would want documentation on the opt-out method for RPM builds.