[LLVMdev] LTO, plugins, binary sizes and performance(take 2)

[Rafael Espíndola]

I run the tests again. This time with only the more interesting
candidates and with the constructor alias optimization enabled. The
gcc used is the one with fedora 13 (4.4.4)

The size of the final clang binary in (KiB) when compiled on linux x86-64 was

gcc   -Os    23073
clang -Os     25251
clang -Os lto 18295

Time to "link" the final clang binary with lto when the gold plugin
was compiled by the various candidates was

gcc:
real	4m52.508s
user	4m50.469s
sys	0m1.187s

clang:
real	4m17.407s
user	4m15.671s
sys	0m1.125s

clang lto:
real	4m14.267s
user	4m12.545s
sys	0m1.114s


Some quick observations:

*) gcc -Os does a good job at producing small binaries, but looks like
it does so at noticeable runtime cost.
*) lto wins both in size and in time.
*) I wonder if the size benefits gcc has at -Os would carry over to
the lto case if implemented in llvm :-)

Cheers,
Rafael