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

[Jan Hubicka <hubicka at ucw dot cz>]

> On Mon, Nov 15, 2010 at 4:25 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> This means O3 level inlining should be turned on also for lto build by
> >> default -- as -O2 lto performance is too unimpressive.
> >
> > I am just re-tunning the inliner and hope to get more speedups for smaller
> > costs than we get right now. ?I however don't think we can resonably enable it
> > as it is at LTO with -O2. We sort of declare that -O2 is the level where
> > compiler optimize hard without bloating code size. Automatic inlining bloats a
> > lot. ?Enabling it at -O2 will make developers who care about code size unhappy.
> 
> Looks like you want to brand LTO as a size optimization technology
> more than performance one :) -- is that the right promotion for lto?

No, I don't want to brand is as size optimization.  I however want -O2 -flto to
be right setting for compiling majority of program in your distro to you good
overall system performance.

The size matters here - you don't want to bloat your distro by 20% to get 4% of
performance benefit when everything is in cache since overall performance will
likely degrade. If this was desirable, everyone would be using -O3 already.  In
my tests (without -fwhole-program) -O3 +LTO bloats code even more than -O3
alone.

-Ofast is for those who want maximal performance now and -O3 for those who
don't care about size but are old fashioned and affraid to use -Ofast ;)

> >at the moment we bypass unit growht
> > at very tiny units via large-unit-insns parameter, but this is not good enough.
> > For medium sized units we need growths as big as 30%, for large units we need 5%.
> > I guess I can either define very-large-unit-growth and very-large-unit-insns
> > to jump down in growth at some point, or define the growth to be function of 1/size.
> > Do we know of better alternatives?
> >
> 
> Mark can provide some suggestions -- he has many inliner patches
> related to performance/size trade off.

I would be definitly interested to see them, too.
> 
> > Enabling such extensively trimmed down automatic inlining at -O2 IMO can make
> > sense if we can prove it makes binaries of about same size and brings
> > noticeable speedups.
> > After all, we want to make LTO selling well - most people will probably repeat
> > mistake you did and try it at -O2 without -fwhole-program. ?The second I am hoping to
> > fight with enabling -fuse-linker-plugin by default as discussed on the summit
> > (that has similar effects to -fwhole-program code quality wise even if underlying
> > implementation is different).
> >
> 
> I don't think that is a mistake --  a large percent of people will
> likely not (be able to) use -fwhole-program for various reasons -- for
> instance shared library build, partially available source, option
> limitations etc. It is therefore more (at least equally) important to

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.

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