🚀 go-pugleaf

This was originally on info-gcc, but I thought it was more inline with
bug-gcc.

Ken Raeburn writes:
>  However, the `cc1' process gets rather large on the PMAX.  (A result
>  of being a RISC machine and being a compiler for a RISC machine, I
>  guess.)
>  
>  One file I've tried building very often (gcc's own insn-peep.c!)
>  causes it to grow to over 32M; I think flow analysis is one of the
>  culprits, allocating an M*N bit array....  Performance is, well, less
>  than wonderful while I'm compiling.  (Never mind that my own machine
>  is only configured for 32M of swap total, so I have to use someone
>  else's for rebuilding gcc itself.)  Extra memory may be cheap for some
>  people, but for me it isn't an option....
>  
>  This is one the reasons why I don't compile much of anything at all on
>  the PMAX on my desk. :-(

One thing to look at is malloc behavior.  I found on the 88k that if
you use the standard System V malloc, there were programs that cause
the compiler to thrash when it allocates very many small data blocks
(the bad case was compiling xcheapmoon whose bitmap has 150,000
elements in an initializer).  By switching over to the GNU malloc
(after making it double word align memory blocks), it improved
performance on the cases that took hours.  Normal compiles though,
still took the same amount of time.

As a point of reference, on the DG 88k AViiON workstation it takes
about 15 minutes from start to scratch to build the compiler (12M
without X, 16M with X running).  Since the 88K is roughly comparable
to the Mips, I would have expected the rebuild times to be in the same
ballpark.