[Interest] building Qt 4.8.7 with gcc 5 and link-time optimisation on Linux

[Thiago Macieira]

On Wednesday 22 July 2015 23:20:40 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > $ git name-rev --tags 1bd27f24fb7f7d82f4b67cffe43e0af644709106
> > 1bd27f24fb7f7d82f4b67cffe43e0af644709106 tags/v5.4.0-alpha1~525
> > 
> > It should work on 5.4 then. The fix for static libraries came with 5.4.1,
> > though.
> 
> Ha, indeed, it's a little bit more complicated when doing out-of-source
> builds. 

Just the running of configure and qmake, of course.

	$srcdir/configure [...]
	qmake -config ltcg $srcdir
	make

> With an explicit reference to the .pro file -config was accepted,
> but I'm not yet sure that it actually changed anything when executed in a
> build directory on my Mac that had already seen a full build. It looks like
> all code was being recompiled, but I didn't see any flto options except in
> the 1st link command, which probably explains why it told me

That won't work if you already have a build. The propagation only works if 
there are no subdirectory Makefiles yet.

If you need to regenerate all the Makefiles, add -r (recursive):

	qmake -r -config ltcg $srcdir

and wait. If you remember Qt 4 configure, it used to do that during configure... 
which is why Qt 5 doesn't.

That's also why Qt 4's configure had the -fast option. Which wasn't the 
default. I don't know why anyone would intentionally choose a slow build with 
no further benefits...

> LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse42.crc32.64.64
> 
> (I'm using -march=native on an i7).

That's qhash.cpp (the only place where we use _mm_crc32_xxx()).

This sounds like qhash.cpp was compiled with -march=native but *linked* 
without. Can you confirm that you see the compiler options passed on the linker 
command-line (-O2 -march=native, etc.)?

Note I have not successfully compiled with LTO with Clang for a while, because 
the linker plugin somehow doesn't get loaded or refuses to understand the LLVM 
bytestream. I only test GCC LTO.

> Is it possible to negate/cancel/revert the effect of qmake -config ltcg? :)

qmake again without it

> 
> > Check if you have mkspecs/features/ltcg.prf.
> 
> That one actually exists in Qt 4.8.7 too ...

That's mkspecs/features/win32/ltcg.prf and it only supported MSVC's LTCG 
feature (which is where the file got the name from).

I moved it from win32/ltcg.prf to the main features dir when I added support 
for GCC, Clang and ICC.

> > It takes noticeably longer to compile :-)
> 
> And even longer to link? ;)

Sorry, I meant the full build.

The compilation itself is faster because there's no code generation for GCC 
(due to -fno-fat-lto-objects). I don't remember whether Clang -flto produces 
LLVM and code or just LLVM bytecode. I know ICC doesn't, but for me it takes 
30 minutes to link QtCore and an infinite amount of time for QtGui (it gets 
OOM-killed due to swap exhaustion before it finishes).

BTW, if you want to force generation of the fat objects, do:
	qmake -config ltcg -config fat-lto $srcdir

Unless you're me, you don't want to do this.

> > the use of -ffunction-sections -Wl,--gc-sections. The libraries are
> > bigger,
> > but that might be due to my use of -O3 (causes code expansion).
> 
> I'd think so; my initial impression with Qt 4.8.7 is that the difference is
> minimal.

I only have evidence for other projects, where LTO did have noticeable runtime 
performance effect. But it's usually the benefits are seen in micro-benchmarks.

LTO does seem to have a noticeable change in code size. Like I said, all 
bootstrapped binaries became smaller as a result because the compiler was 
better able to eliminate dead code. That's often the result of the -fwhole-
program part of -flto.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center