Unit at time compilation mode II

[Jan Hubicka]

> > On Tuesday, February 11, 2003, at 02:17 AM, Zack Weinberg wrote:
> > >(That would entail that unit-at-a-time compilation was mandatory,
> > >which I think should be just fine particularly if we can knock down
> > >the size of DECL nodes a bit.)
> > 
> > I hope this doesn't have a negative compilation speed impact on a small 
> > (128M) machine on real code, either by itself, or in conjunction with 
> > pch.
> 
> I've sent some analysis of it earlier to the list.  In the current form
> it brings about 1% speedup on i386 with -O2 (so no inlining, just
> calling convetion changes).  This seems to be enought to elliminate the
> slodown the patch causes (not by itself, but by exposing more memory to
> GCC).  On the other architectures not benefiting from the local function
> optimization yet the speedup is about 0.5-0.7% (measured on x86-64)
> there will likely be 0.3-1% slowdown.  (I measured 0.6% on x86-64)

Sorry, I am preparing for the exam and apparently things got mixed up in
my memory.  The exact numbers are as follows.

For 386 the SPEC time goes from 1384s to 1392s, so there is small
slowdown.  (first is mainline compiler, second is mainline+unit-at-time
aptch enabled at -O2, both with -O2).  For SpecFP the compiler actually
gets slightly faster (486->477s).  This shows how much it depends on
codebase you are compiling.

However the bootstrap time with unit-at-time enabled by default goes up
from 2794 to 2829 (1% slowdown), this gets down to 0.3% when unit-at-time
compiler is used in stage1 as well.

I hope the change has enought of potential to reverse the scores :) This
is just start and I believe there is number of low hanging fruits
comming from callgraph code and together with some improvements at
datastructures/ggc side it won't be dificult to fix.  (I know that this
is common optimistic opinion about many GCC enhancements that cause
slowdowns, but in this case we are still safe by having the fallback of
not enabling unit-at-time at -O2).

Honza