LTO'ing LibreOffice With GCC 6

[hubicka]

Debug info? I think, optimizations usage in debug builds is quite rare — unless someone debugging a bug introduced by optimizations. I mean, it is, of course, useful, but I wouldn't call it a blocker for widespread.

debug info for production binaries is useful when you can not reproduce the crash yourself and you do have a core dump...

[carewolf]

If you mean ICF, it never really merged functions compiled with different instruction sets. Before GCC 5 the optimization option handling was sloppy: at compile time the optimization options used was applied, at link time the compilation continued with options passed to linker. GCC 5 fixes that. I am not quite sure of the situation in LLVM. LLVM 3.5 behaved in similarly broken way but there was some efforts to fix that.

Right, I was talking about a mix of two different problems. With LTO the main problem was that specific compiler flags for individuals source files used be unreliable, because many optimizations including architecture choice is done at linking time.

The problem with mixed code and wrong instructions can happen even without LTO, when the linker find multiple compiled copies of the same function. and chooses one of them at almost random, but it usually only triggers when the compiler chooses to to not inline a function declared inline in header, which can create multiple version of the function to the programmer's surprise.

Since you in GCC 4.9 had the half-compiled object files, and did inlining at link time with multiple already compiled function, it could inline the wrong version of a compiled inline function, even when the compiler did decide to inline it. At least that is the only way I can explain how I found leaking AVX instructions in files that only shared headers with AVX compiled object files.

[hubicka]

The problem with mixed code and wrong instructions can happen even without LTO, when the linker find multiple compiled copies of the same function. and chooses one of them at almost random, but it usually only triggers when the compiler chooses to to not inline a function declared inline in header, which can create multiple version of the function to the programmer's surprise.

Since you in GCC 4.9 had the half-compiled object files, and did inlining at link time with multiple already compiled function, it could inline the wrong version of a compiled inline function, even when the compiler did decide to inline it. At least that is the only way I can explain how I found leaking AVX instructions in files that only shared headers with AVX compiled object files.

Yeah, mixing COMDAT functions compiled with different flags is sloppy. It hits, for example, firefox which compiles some files with -O3 and some with -Os. It happens that the inline function is not inlined and -Os version wins the merging even though it is called from -O3 built object file. Linker generally works by choosing the first one in linking order, so you can help this by ordering the object flies correctly, but this is not specified and reliable either.

Indeed with LTO you may trigger this more often because only early inlining happens at compile time and late inlining happens after COMDAT merging. It may make previously latent bugs to surface.

GCC 6 adds support for transparent aliases which makes it possible for compiler to internally hold multiple bodies of every function. It may be possible to improve this situation for GCC 7 though it is not really clear what would be ideal behaviour here. One Definition Rule doesn't really consider optimization flags at all and all of this are difficult QOI issues. It is not really clear what to do when you compile one body with conflicting ISA settings.

[carewolf]

Yeah, mixing COMDAT functions compiled with different flags is sloppy. It hits, for example, firefox which compiles some files with -O3 and some with -Os. It happens that the inline function is not inlined and -Os version wins the merging even though it is called from -O3 built object file. Linker generally works by choosing the first one in linking order, so you can help this by ordering the object flies correctly, but this is not specified and reliable either.

Indeed with LTO you may trigger this more often because only early inlining happens at compile time and late inlining happens after COMDAT merging. It may make previously latent bugs to surface.

GCC 6 adds support for transparent aliases which makes it possible for compiler to internally hold multiple bodies of every function. It may be possible to improve this situation for GCC 7 though it is not really clear what would be ideal behaviour here. One Definition Rule doesn't really consider optimization flags at all and all of this are difficult QOI issues. It is not really clear what to do when you compile one body with conflicting ISA settings.

In Qt we compile the architecture specific files without lto and pch, even when enabled them for everything else, and try to make them as minimal and flat as possible and only call functions that are declared always_inline.

Using the gcc function targets would be better, but that doesn't work cross platform with different compilers, it doesn't even really work outside x86 with gcc.

[hubicka]

In Qt we compile the architecture specific files without lto and pch, even when enabled them for everything else, and try to make them as minimal and flat as possible and only call functions that are declared always_inline.

Using the gcc function targets would be better, but that doesn't work cross platform with different compilers, it doesn't even really work outside x86 with gcc.

Interesting. I was kind of aware of this problem in the case of firefox but did not know QT was hit more seriously. Using target and optimization attributes will liekly give you less wrong code surprises, but it also it will prevent inlining function compiled with default ISA into function compiled with explicit target attribute, so it may hurt code quality of those loops. I am just looking into improving this situation for Firefox and extend number of permitted transitions in the inliner.

[curaga]

Can't wait for gcc 6.2 (never use the first release of anything important), as mentioned in the webkit thread, the memory use really needs to get lower, gcc 5.2 uses too much.

I've always wondered, why binary distros never provide packages compiled with LTO. Even critical to performance ones, like Mesa, Xorg, browsers…

TinyCore does build many things with LTO for the size benefit, and TinyX even applies LTO by default in its configure script, if the compiler supports it. -- As an aside, I built LO a few weeks ago. It took fucking 15 hours. Seriously, this thing needs a swift kick in the rear.

[SystemCrasher]

I've tested GCC with LTO on fairly large program and got code size down from 5 MiB to 4MiB. Without any performance penalties at all. Nice gain for "nothing". Uhm, well, GCC is quite a memory hog if it chews on large chunk of code, so LTO linking of large programs could be demanding in terms of memory.

I've also used LTO to build a plenty of various programs and I never had LTO-induced bugs, despite of mumblings of some phoronix readers. So basically tradeoff appears to me like this: smaller code size at cost of slower compile time and larger RAM use during compilation. Though I mostly used just -flto to be on safe side. On performance side, it generally stays more or less the same, so code size reduction is nice, if you can afford resources t takes during compile time.