For some time now I was curious on what the size impact of LTO was. I
decided to test this with a large C++ app, clang was a natural choice.
With PR8313 fixed with the proposed patch and PR8300 avoided by
disabling constructor aliasing I was able to hack clang to bootstrap
with LTO enabled using the gold plugin.
I did the testing on linux x86-64. Gcc is the 4.4.4 included with
Fedora 13. The results are:
gcc -O3: 32MB
gcc -Os: 25MB
clang lto -Os: 22MB
I then decided to try to link without export-dynamic, since it
produces some fairly large tables and blocks many optimizations. The
new results were
gcc -O3: 30MB
gcc -Os: 23MB
clang lto -Os: 18 MB
The full patches I used are attached. I hope to get the non-hackish
bits reviewed, starting by the fix to 8313.
Cheers,
Hi Rafael,
I did the testing on linux x86-64. Gcc is the 4.4.4 included with
Fedora 13. The results are:
gcc -O3: 32MB
gcc -Os: 25MB
clang lto -Os: 22MB
how does clang -Os without lto do? Also, what about gcc-4.5 with -flto?
Ciao,
Duncan.
Wow, nice results. Please split the patches out according to what they do.
Is there any impact on clang compile time by building with LTO? What about build times? 
-Chris
Wow, nice results. Please split the patches out according to what they do.
The first two are attached to PR8313
Is there any impact on clang compile time by building with LTO? What about build times?
I didn't measure, but I noticed about 4 minutes cpu time while linking
clang. It is interesting that the check for circular dependencies got
a lot slower with nm loading plugins..
-Chris
Cheers,
how does clang -Os without lto do?
Not sure. Should be able to try it next Tuesday.
Also, what about gcc-4.5 with -flto?
Last time I tried gcc could not build itself with LTO, so I am not all
that excited to try it
Ciao,
Duncan.
Cheers,
Yeah, LTO support in 4.5 is fairly brittle. You want to use 4.6
(trunk, currently) for LTO-based bootstraps.
Diego.