Re: lto

[Jan Hubicka <jh at suse dot cz>]

> I am agree with you.  We should not forget embedded market where the 
> code size is more imortant but we should provide an option for  market 
> on which  Pathscale/Intel/Sun compilers are oriented.
> 
> With this point of view, we have a lot of resources because gcc 
> generates the smallest code.  E.g. In averages Intel compiler generates 
> 80% bigger code for SPECINT2000 with -O2 and 7 times bigger with -fast.  
> It generates even bigger code with -Os (code size optimizations) than 
> GCC for -O3.  The same is about the compilation speed.  GCC with -O3 is 
> much faster (30%-40%) than all mentioned compilers in peak performance 
> mode (-fast, -Ofast).  So I think we have some resouces which we could 
> spend to improve the code performance for this market.

Actually with my experiments about --combine and -fwhole-program
combination I was more easilly getting noticeable code size savings for
"LTO" at -O2 than noticeale performance improvements at -O3 (I didn't
get even that 4% you mention on pathscale, it was about 1-2% if I remember
correctly with about 20% code size regression).
Just few of SPEC2000 benchmarks has important crossmodule inlining
oppurtunities in them).  I will try to dig out the numbers.

So the initial LTO will probably be good for people caring about code
size: not just the embedded marked, but I hope that as soon as we get
--lto resonably working for C good portion of Linux distro can be built
this way with noticeable benefits at load times of all the small tools
we use daily.  With code/data segment reordering we ought to get less
memory dirtified at during initialization of compiled application too.

It is hoped that as we implement better IPA alias analysis and similar
optimizations, the need for inlining of large function bodies will be
actually reduced. IP RA fits pretty well this plan IMO.

Honza