GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

[Xinliang David Li]

On Mon, Nov 15, 2010 at 5:39 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > Fortunately linker plugin solves the problem here and this is why I want to
>> > have it by default.  GCC then can do effectively -fwhole-program for binaries
>> > (since linker knows what will be bound elsewhere) and take advantage of
>> > visibility((hidden)) hints for shared libraries same way.  Most of important
>> > shared libraries gets visibility ((hidden)) right.
>> >
>> > It is sad that LTO w/o linker plugin doesn't give that much benefits.
>> > Ideas are welcome here.
>>
>> Linker feedback will be limited here -- mostly global variable
>> aliasing (as I remember only 2/3 spec programs benefit from it), it
>> helps  You don't get whole program points-to, whole program mod-ref
>> (with context sensitivity), whole program structure layout. The latter
>> are the real kickers (in terms of SPEC performance), but promoting LTO
>> with those numbers can be misleading as many programs won't get it.
>
> Well, I am speaking of our linker plugin here.  What it does is to pass GCC
> resolution information so it knows what symbols are bound externally. Since
> typically you link LTO alone or with small non-LTO part, most of symbols are
> not bound and thus effecitvely you get -fwhole-program (-fwhole-program just
> declare everything static except for main ())
>
> We don't really do whole program points-to or structure layout.

gcc will eventually, right?

> Mod-ref is just
> simple ipa-reference code. How you get context sensitivity on mod/ref?

mod-ref relies on points-to. With context sensitive points-to, you can
also get CS mod-ref -- basically mod-ref info per callsite.

Thanks,

David
>
> Honza
>>
>> David
>>
>> >
>> > Honza
>> >> sell lto without -fwhole-program.
>> >>
>> >> Thanks,
>> >>
>> >> David
>> >>
>> >> > Honza
>> >> >
>> >
>