Consider building with -flto

sipa commented at 10:16 pm on June 16, 2017: member

GCC since version 4.5 has supporting LTO building. In this mode, compiling cpp files to object files does not emit the final assembly code yet, but an intermediate representation which is used to produce the assembly at link time. This allows the compiler to perform inter-module optimizations; most notably it permits inlining across module boundaries.

Advantages:

Smaller binaries (code from headers does not get duplicated into multiple objects anymore).
Faster code (more optimization opportunities)
Lower build-time memory requirements

Downsides:

Slower building
Requires modern compilers
Debugging sometimes gets harder
Before GCC 4.8: double size object files

I believe we should consider producing release binaries created using LTO, if the compiler is sufficiently modern. It categorically removes the concern about whether code should go in header files or not (before, moving implementations to .h files would sometimes be needed for performance reasons - with LTO that is not a good reason anymore).

Opinions?

sipa added the label Brainstorming on Jun 16, 2017

luke-jr commented at 10:24 pm on June 16, 2017: member

I think using dynamic libraries would be better unless there’s a significant performance improvement from LTO…

gmaxwell commented at 0:26 am on June 17, 2017: contributor

@luke-jr this more or less completely orthogonal from dynamic libraries.

luke-jr commented at 0:50 am on June 17, 2017: member

I was under the impression LTO was fundamentally incompatible with dynamic libraries, due to its optimisation methods?

sipa commented at 0:52 am on June 17, 2017: member

LTO code can statically or dynamically link non-LTO code.

laanwj commented at 12:28 pm on June 29, 2017: member

Seems like a good idea to me.

Static/dynamc linking is orthogonal, although one option would be to build the depends with LTO as well, then with static linking the entire executable can be optimized by the linker, also calls crossing library boundaries. But I"m not sure this is worth the extra build time - the important dependencies from a performance point of view are secp256k1 and leveldb and those are already internal.

gmaxwell commented at 0:52 am on July 6, 2017: contributor

@theuni Is there anything special in the build scripts that would get in the way of this?

theuni commented at 5:03 pm on July 6, 2017: member

@gmaxwell It depends on what the definition of LTO is here. As @laanwj said, taking this as far as possible, the dependencies can also be built with LTO, which ends in one final massive link. There were a few issues with that last I tried, most having to do with ODR violations (bdb and qt, iirc).

For just LTO’ing our own builds, I think it should just work if the compiler is capable.

We could start by adding an “–enable-lto” configure option and letting people take it for a spin.

TheBlueMatt commented at 5:12 pm on July 6, 2017: member

Yes, we really should have a configure option, it would be so much easier than manually overriding all of the various wrappers that we have to do now. Still, I dont think we can enable this for a while, eg debian jessie still fails to build with LTO without manually compiling util.cpp without LTO (something to do with header-defined destructors being lost during link, specifically in boost::filesystem).

laanwj commented at 5:29 pm on July 6, 2017: member

Still, I dont think we can enable this for a while, eg debian jessie still fails to build with LTO without manually compiling util.cpp without LTO

It should definitely not be enabled by default! Programs usually shouldn’t add non-standard compilation flags by default unless necessary.

AFAIK the only thing being discussed here is whether to enable it for the gitian build, and thus the distributed executables.

theuni commented at 8:38 pm on July 6, 2017: member

Well if we’re going to do it for the Gitian builds, we want a trivial way to reproduce that outside of Gitian so that we’re not surprised by any odd effects. So I think a configure option (which Gitian and maybe Travis) use, would be the way to go. @laanwj I’m unsure from your last comment if you’d be opposed to that?

laanwj commented at 9:14 pm on July 6, 2017: member

Yes configure option is a good idea of it is disabled by default like the glibc compat option.

On Jul 6, 2017 10:38 PM, “Cory Fields” notifications@github.com wrote:

Well if we’re going to do it for the Gitian builds, we want a trivial way to reproduce that outside of Gitian so that we’re not surprised by any odd effects. So I think a configure option (which Gitian and maybe Travis) use, would be the way to go.

@laanwj https://github.com/laanwj I’m unsure from your last comment if you’d be opposed to that?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/10616#issuecomment-313512634, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHutib92Mu6LTgOM9wlgKMfbF9wB8TJks5sLUXNgaJpZM4N9Akv .

sipa commented at 9:57 pm on July 16, 2017: member

Benchmarks show that at least for me (gcc 6.3, with otherwise normal build options), -flto significantly slows down IBD.

laanwj commented at 3:36 pm on July 20, 2017: member

Slower?!? that’s curious.

eklitzke commented at 7:14 am on March 10, 2018: contributor

My experience with -flto is that it’s often broken on GCC 4.x, and it can confuse GDB (especially on older versions of GDB). I am against this unless there’s a clearly demonstrated performance improvement.

laanwj commented at 12:46 pm on March 10, 2018: member

I am against this unless there’s a clearly demonstrated performance improvement.

I don’t think it’s possible to disagree with that. If there is no demonstrated performance improvement, why would one enable an optimization, just for extra fun untangling the assembly at debugging time? :-)

MarcoFalke added the label Build system on Mar 11, 2018

MarcoFalke commented at 6:49 pm on June 24, 2018: member

Should this issue be kept open in light of the above comments? (no apparent improvement gains)

laanwj commented at 7:05 pm on June 24, 2018: member

I think it’s fine to close it. This might change with a newer or different compiler, but I don’t think it warrants having an issue open.

laanwj closed this on Jun 24, 2018

practicalswift commented at 3:06 pm on September 20, 2018: contributor

Some promising clang LTO results reported in #14277 :-)

DrahtBot locked this on Sep 8, 2021

Consider building with -flto #10616