Re: gcc 3.5 integration branch proposal

[Jan Hubicka <hubicka at ucw dot cz>]

> 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 ?

No, actually the format is specific to even compiler settings.
This is because the profile can be read back to the compiler and can not
be addressed before tree-SSA is accepted.

It is however possible to make profledbootstrap faster with some effort.
At the moment we build all target libraries with profiling that has
relatively huge overhead especially for libjava.   We can try to put
together smaller testsuite, as the size of train set is usually not
important.

My experience is that C frontend works well when profilebootstrapped
only for C language where train run happens only for libgcc that is very
small and specific piece of code, so I would assume that simple tests
would be enough.

My original implementation of profiledbootstrap were mostly to test the
feature and thus I preferred when it is executed heavilly (doing so
motivated many optimization to the profiling mechanizm itself), but
perhaps it is good idea to revisit it.

It makes three stages - stage1 and stage1 is used to build both the
compiler used to produce feedback and the compiler to using the
feedback.  This shall not be much slower than usual 3 stage bootstrap
then.  Only disadvantage is that feedback stage (equivalent of stage3)
is built with non-optimizer stage1 compiler.

If frontend maintainers propose some smaller train runs, we can try to
put together this plan.
> 
> 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.

This is not supposed to happen as long as you didn't changed your tree.
I sometimes re-do make profilebootstrap after stopping it by ctrl+c and
it seems to work, so I would be interested knowing more details if you
run into this problem again.

Honza