Re: Using FDO to speed up compiler?

[Jan Hubicka <jh at suse dot cz>]

> 
> On Wednesday, February 12, 2003, at 02:23  PM, Jan Hubicka wrote:
> 
> >>On Wed, Feb 12, 2003 at 10:17:10PM +0100, Jan Hubicka wrote:
> >>>The number reminds me not-so-related note.  I've also hacked 
> >>>makefiles
> >>>in the past to add profiling into the bootstrap.  I used "make check"
> >>>for train run and measured speedup in between 5-10% on compiling
> >>>on compiling binutils on early rtlopt-branch tree.
> >>
> >>Nice.
> >I will have to re-benchmark the numbers as many things has changed 
> >since
> >that , but hope it won't change in the negative direction :)
> >One of important factors was code placement, as we had extraordinally
> >large insn-attrtab that time.  With DFA this problem has changed a bit.
> 
> This was on x86 right?  FWIW I tried this on ppc a month or so ago and
> it made no significant difference.

I've re-done my experiment (again on x86).  What I precisely did is the
following:

1) configure with default GCC
   make
   make install
2) configure with newly installed GCC and into noopt directory
   make
   make install
3) configure with noopt GCC and -fprofile-arcs -O2 flags
   make
   make check
   rm `find . -name "*.o"`
   CFLAGS="-O2 -branch-probabilities" make
   make install

Then I make two build directories for binutils and build both.
Old compiler takes somewhere from 3:20 to 3:28 while old compiler takes
somewhere from 2:59 into 3:08
That gives about 7.5% speedup.  I also get 8% speedup on compiling
combine.c alone, so this seems to be reproducible quite easilly.

I tried one other architecture and the results was basically the same.
Also binary get 3.6% smaller.  Interesting is distribution of code size
about 1/3rd of code is marked as hot, 1/3rd as unlikely and 1/3rd of
normal.  I guess my heuristics for hot code is way too conservative, or
our testsuite is not very representative train run...

I've also hit quite important problems - the new profile merging code
does tons of small read/writes/seeks to it takes important amount to
merge the profile and make check takes important amount of time.
(in fact about 50% of CPU time is then consumed by kernel)

Also I found important compile time problem I've already fixed that
makes me believe that make profiledbootstrap would be usefull test for
profiling code anyway.

Honza