Re: gcc 3.5 integration branch proposal

[Marc Espie <espie at nerim dot net>]

On Mon, Jan 19, 2004 at 02:35:01PM +0100, Jan Hubicka wrote:
> > On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote:
> > 
> > > 	Did you build head configured with --disable-checking?
> > 
> > Rebuilt with --disable-checking, and double-checked the options. There
> > was a bug that meant I was not -O2 in both cases.
> > 
> > Now, the actual options are 
> > -Wall -Wstrict-prototypes -Wmissing-prototypes
> > -Wno-uninitialized -Wno-format -Wno-main  -fno-builtin-printf
> > -fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing
> > in both cases.
> > 
> > And it's still a bit slower:
> > 
> > gcc 3.3.2:
> >   527.98s real   421.02s user    30.36s system
> > 
> > gcc -head  with --disable-checking:
> >   544.91s real   439.52s user    30.27s system
> > 
> > 
> > Okay, the slow-down is not as marked as with --enable-checking, but it
> > still does exist: 4% is something.
> 
> You may consider using profiledbootstrap.  It makes bootstrap slower,
> but it pays back in compilation time later.
> 2 hours of whole build may already make it pay back.  In fact I would be
> extremly curious about that.

Yep, profiledbootstrap is very, very slow, but the results are a little
encouraging:

  515.03s real   389.54s user    30.42s system

So, it is slightly faster than 3.3.2...

I'll try doing some profiling for you guys, and building a complete archive
that you can experiment with.

Now, for the killer question: assuming the OpenBSD project, at some point,
moves to a recent gcc, we might want to have profile-directed compilation,
but we definitely can't afford to run a full profiledbootstrap each time.

Is the format of profile information such that, say, it could be stored
in arch-dependent directories, and then used for the compilation ?

I'm asking this, because I had to kill one profiledbootstrap, and when
I tried to resume it, it didn't work and told me I had used the wrong
options.