Re: Explicitly release memory used by varrays

[Jeffrey A Law <law at redhat dot com>]

On Mon, 2004-09-13 at 10:09, Jan Hubicka wrote:

> Compared to my patch simplified to ggc_free on the two varrays (leaving
> the third ggc_free aside) it saves just about the half of memory - the
> rest is burned in the fact that memory representation of SSA_NAMEs
> increased.  Originally we produced 42544422 bytes of garbage, my
> simplified patch reduces it to 40891018 bytes, while SSA_NAME expansion
> patch 41719898.
Not a huge surprise.  The size of the SSA_NAME tree node went from 36
bytes (which is the same as a 2 operand EXPR node which as a special
GC pagesize) to 64 bytes with your change.

I'm actually quite tempted to split the two issues apart (vrp_data
vs const_and_copies) and try to tackle them separately.  I kept
thinking of vrp_data as the global range information computed on
a per SSA_NAME basis.  vrp_data is actually a list of statements
which constrain the value of an SSA_NAME and is thus highly 
context sensitive.

It's also the case that I suspect that vrp_data is quite sparse
in the amount of information it carries -- we might want to just
use a hash table.  We'll need to investigate the various tradeoffs.

When we do add global range information, we will want that info
to be a first class entity hung off the SSA_NAME, but we're not
there yet.

We can move const_and_copies into the SSA_NAME node which will
increase its size by 4 bytes and thus move it into the 40 byte
special size object bucket.    A quick experiment with that
shows that we're saving roughly 8M in GGC allocated memory with
Gerald's testcase.

jeff