This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Re: A user question (was: Re: Faster compilation speed)


Hi,

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
EXECUTE_IF_SET_IN_BITMAP().


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]