Re: Tremendous increase in compile times for 3.4.1 with -mcpu=G5

[Michael Matz <matz at suse dot de>]

Hi,

On Tue, 10 Aug 2004, Bradley Lucier wrote:

> > I suppose, but it's not obvious why that would cause local_alloc to do that
> > much more work.  Could we be tickling a bad algorithm in local-alloc?
> 
> There's more discussion in the PR,
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16975
> 
> It appears that the main problem may be a slowdown in sbitmaps (used in
> invalid_mode_change_p) caused by using HOST_WIDE_INTs.  See also

No, sbitmaps are not used in invalid_mode_change_p which is culprit 
function.  The problem is, that with -mcpu=G4 the subregs_of_mode bitmap 
(_not_ sbitmap) is sparsely filled up to bit 981728 in 197 list elements.

For G5 it is filled up to bit 1621359 scattered over 9011 elements.  I.e. 
not as sparse.  The function in question iterates over a subset of bits in 
that bitmap, starting with a predefined one.  It is searching for the 
element containing this start bit which is so much slower with G5.

I suspect the same reason as David mentioned why this bitmap is filled 
with more bits.  There simply are more references to subregs.

Bradley: was 3.4.0 better?  It should have shown similar behaviour.

As for fixing this: I think it's not that easy without giving up the 
additional functionality which caused this reimplementation of the old 
CLASS_CANNOT_CHANGE_MODE macro.  We could either provide a per-pseudo 
bucket (bitmap or sbitmap) of which modes it was encountered in.  This 
would take quite some more memory than the current bitmap, though.


Ciao,
Michael.