LTO, plugins, binary sizes and performance(take 2)

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 :slight_smile:

Cheers,
Rafael