Statistics for varray GGC memory consumption

[law@redhat.com]

In message <20040120000219.GB7878@kam.mff.cuni.cz>, Jan Hubicka writes:
 >> In message <20040119232939.GA7878@kam.mff.cuni.cz>, Jan Hubicka writes:
 >>  >I just killed the old table, but I am attaching new one, where I am half
 >>  >way pusing varrays back to MALLOCed memory.
 >> Ugh.  I really wouldn't spend a lot of time doing that.  As I stated before
 >,
 >> there is a pending design change which would significantly reduce the
 >> amount of varrays and hash tables we maintain in the dominator optimizer.
 >> 
 >> Plus there's some trivial changes which could be made which would reduce
 >> the silly growing simply by not using varrays in the first place for a
 >> fixed length array.
 >> 
 >> Let's fix those things before we start mucking around with how varrays
 >> work.
 >
 >What do you propose to do for varrays that are growing and yet they
 >don't need to live in GGC.
Such as?

I certainly know of some cases where we're using a varray and growing it,
but for which we don't actually want/need a varray because when we grow
it, we clear the damn thing...  (const_and_copies for example).  
const_and_copies would be a great example of why I want a "safe array".
(an array with bounds checking, no more, no less).

I would much rather see us look at how we're using varrays and make
sure that we're using them sensibly rather than going in an mucking
around with changing the backing store for varrays.

Second, I would much rather see us eliminate varrays that we simply don't
need because there are better designs for the datastructures we need.
For example, the true/false exprs local varrays both exist solely because
we don't have a good, low overhead interface into the main avail_expr
hash table.  I'm still mentally hashing through how to rework our
interfaces into the hash table so that I can simply make two block
local varrays disappear without having to create a bazillion silly 
tree nodes.

Third, I think we need to look at the remaining varray uses (which presumably
actually use the properties of varrays that we need) and make sure that
the way we allocate & grow them is sensible.  For example, anything which
is sizing a varray with 2**n elements is flat out stupid, much like
anything which sized a PHI node as 2**n elements.

I suspect you'll find that if we actually do those things that our varray
usage, as well as the amount of varray grow calls will drastically be reduced
(how do I know that?  Because I've actually prototyped some of this stuff
already).


jeff