This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Major bootstrap time regression on March 30
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: gcc at gcc dot gnu dot org, Diego Novillo <dnovillo at redhat dot com>
- Date: Mon, 04 Apr 2005 21:52:57 -0400
- Subject: Re: Major bootstrap time regression on March 30
- References: <200504042249.56749.stevenb@suse.de>
On Mon, 2005-04-04 at 22:49 +0200, Steven Bosscher wrote:
> Hi,
>
> We have a bootstrap time regression since March 30. Bootstrap times
> on Diego Novillo's SPEC box went up from (an already high) 5500s to
> almost 8000s, see:
> http://people.redhat.com/dnovillo/spec2000/gcc/gcc-compiler-build-secs_elapsed.png
>
> On IRC a patch possibly causing this regression was mentioned: the
> subvars correctness changes from Dan. He also posted a heuristics
> change patch a day earlier, which has not been reviewed yet, see:
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02666.html. If the
> subvars patch really is the problem, this heuristics patch should
> fix it.
> Could someone (hi, Diego!) review Dan's patch? And if that patch
> does not fix this, we'll have to look for someone else to blame ;-)
After further review, i'm pretty sure i'm not the cause here.
I ran cc1 -O2 over *.i in cc1-i-files and cc1plus -O2 over *.ii with and
without the patch, and the times with the patch are only about 30
seconds lower out of 20 minutes.
Somehow, i don't remember cc1-i-files taking 20 minutes.
I also tried it with -fno-tree-salias, and it did not save time over
using the patch (IE still 20 minutes).
I suspect something more fundamental is going on here.
SPEC iteslf also didn't show a similar build time regression:
20050329:mean:CFP2000:base:build:secs_elapsed:216
20050330:mean:CFP2000:base:build:secs_elapsed:218
20050401:mean:CFP2000:base:build:secs_elapsed:216
20050329:mean:CFP2000:peak:build:secs_elapsed:221
20050330:mean:CFP2000:peak:build:secs_elapsed:226
20050401:mean:CFP2000:peak:build:secs_elapsed:221
20050329:mean:CINT2000:base:build:secs_elapsed:310
20050330:mean:CINT2000:base:build:secs_elapsed:312
20050401:mean:CINT2000:base:build:secs_elapsed:318
20050329:mean:CINT2000:peak:build:secs_elapsed:354
20050330:mean:CINT2000:peak:build:secs_elapsed:356
20050401:mean:CINT2000:peak:build:secs_elapsed:361
(These are within the normal fluctuation range for spec build times,
AFAIK)
However, Check out a diff of build-20050329.log.gz vs
build-20050330.log.gz
and a diff build-20050330.log.gz vs build-20050331.log.gz
The latter diff consists of almost no differences (just a couple decimal
places of automata generation).
However, the former has large changes in the way libjava is being built,
though i can't quite figure out what is going on.
I suspect that is where our bootstrap time regression lies.
--Dan