Compiler uses a lot of memory for large initialized arrays

[Mark Mitchell]

Peter Barada wrote:
>>>Or can't we seek in the asm output and overwrite previously written values?
>>>Might be slow, though.
>>
>>Even if that were sensible, where will we remember the file offsets
>>of each and every element :)

I think overwriting stuff in the assembler is a horrible idea.

I also think that trying to acheive 2.95.3 memory usage for huge arrays 
is foolish.  Since then, we've deliberately substantially increased the 
amount of memory we need for lots of things: function-at-a-time is more 
expensive than statement-at-a-time, and now we're unit-at-a-time for 
many compilations -- as we should be.  Most compilers suck up lots of 
memory with vast arrays; I don't think we need to be different, alleged 
regression or not.

However, the C++ front end (and perhaps the C front end) do some pretty 
silly stuff when contstructing the arrays.  I believe that when I 
analyzed this, I determined that there were factor-of-eight sorts of 
improvements possible.  That's what I think we should fix.

We've already got some of that, in that, for example, Nathan's changed 
things so that we share integer constants.  The next major step is to 
change CONSTRUCTOR to use an array, rather than a linked list, of 
elements for CONSTRUCTOR_ELTS.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304