This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Re: A user question (was: Re: Faster compilation speed)
- From: Michael Matz <matz at suse dot de>
- To: Mike Stump <mrs at apple dot com>
- Cc: Marco Morandini <morandini at aero dot polimi dot it>, <gcc at gcc dot gnu dot org>,<gcc-patches at gcc dot gnu dot org>
- Date: Wed, 14 Aug 2002 13:10:26 +0200 (CEST)
- Subject: Re: PATCH: Re: A user question (was: Re: Faster compilation speed)
On Tue, 13 Aug 2002, Mike Stump wrote:
> :-( The biggest single culprit count wise is some aggressive checking
> code. The below change save 1.5 minutes of compile time out of 5
> minutes on an n=20,000 case. The top of the tree is much worse than a
> gcc 3.1 compiler, 5 minutes compared to 56 seconds.
This is a typical case why I strongly dislike such arbitrary cutoff means
to avoid slow behaviour instead of redesigning how it works. From the
code you posted it seems, that the blocks bitmap is extremely sparse (in
the second loop only one bit is set in evry case, the second loop only
seems to set one bit each time by pure luck), but still it's completely
traversed, through pointer chasing even (the bb double linked list).
This suggests to change the interface of count_or_remove_death_notes() to
take a bitmap (not sbitmap), and rearrange the outer loop of it, to use