mainline "exploding"

Jan Hubicka jh@suse.cz
Mon Oct 20 15:08:00 GMT 2003


> On Mon, Oct 20, 2003 at 12:56:24AM +0200, Gerald Pfeifer wrote:
> > On Sat, 18 Oct 2003, Jan Hubicka wrote:
> > > Hi, here are timmings of all sollutions I've proposed.
> > >
> > > 1 Current mainline                               0m57s
> > > 2 unit-at-a-time by default                      0m32s
> > > 3 Using different limits with old heuristics     0m27s
> > > 4 unit-at-a-time by default + small limits at O1 0m24s
> > > 5 New non-unit-at-a-time inlining heruistics     0m25s
> > >
> > > So all of them cuts the time to roughtly half of it.  My preference is
> > > either 5 or 2, but I would be happy with any of it (3 is IMO worst one).
> > 
> > To me, 5 or 4 look nice, both from the timings and abstractly.
> 
> I think I prefer 5.  The maintainence burden is lower, and

Really hope it won't be maintenance headache as it is mostly just
another interface to same inlining heuristics.

> the above shows good practical results as well.
> 
> Jan, go ahead and check that one in.

Thanks!
The smaller compile times above appears to be quite typical situation
for complex compilation unit. In simple cases both heuristics are
equivalent, they start to differ when compilation units starts hitting
size limits and incremental one behaves inferriory by producing less
inline thus resulting in better compilation times and worse perofmrance.
I experimented with the incremental code enbled together with -O3
-funit-at-a-time and measured about 0.4% difference on SPEC that is not
too bad result I would say.  Still better than old heuristics but SPEC
is not best benchmark for this.

I hope that with -funit-at-a-time enabled by -O2 we will get the
compatibility problems fixed (kernel seems to be fine now, glibc is
almost fine with my other fix for renaming assembler name, our runtime
seems to be best fun, I will try to dig into it) I will try to write
some notes encougrating users to fix their code into 3.4 news file :)

Honza
> 
> 
> r~



More information about the Gcc mailing list