Varray memory consumption strikes back

[Jan Hubicka]

> The varrays are a natural way of building unwindable state into
> the optimizer, which in turn avoids the horrible path following
> behaviors found in CSE.  However, there are ways to reduce the
> number of varrays we allocate.

Actually it seems to me that use of varrays for stack holding local
datastructures of the recursive walk of dominance tree is one of these
that makes kind of sense.  What I don't understand at all is why these
needs to be garbage collected and why we didn't developed some stack
implementation that don't need moving data around at reallocation and
don't have more convenient API than obstacks.

What is still behind me why we do have so often big varrays of small
varrays (like "vrp records" array where each varray occupy 24 bytes and
is never resized).
> 
> One such way is to recycle them as I've already suggested.
> 
> ggc_free-ing them may be a solution as well, but I have my
> reservations given my experience with this code already.
> 
> Another would be to have a single varray for expressions rather
> than having a varray per block for expressions.  Each element in
> that varray would have the expression and the block associated
> with the expression.
> 
> In the finalizer, you pop elements off that varray as long as
> their block matches the block we are leaving.  Remove each
> of the popped elements from the available expression hash
> table.
> 
> The advantage of that scheme is that we allocate fewer block
> local varrays.  However, the one varray we do allocate will
> tend to be large and we have to allocate a two word element
> for each entry in that varray (pointer for the expression
> and a pointer for the block containing the expression).  It's
> not clear if that will be a notable win over what we've got
> or what has been proposed.
> 
> I haven't prototyped that code, but I don't think it would be
> terribly hard to do so and run some experiments to see if it's
> a worthwhile direction.

This sounds like _nea_t idea, especially if we later develop sanier
representation of the stack.

It is also easy to avoid the explicit BB values for each entry in the
array for instance by pushing NULL as frame separator.  Would be
possible for you to give this a try?

> block_defs ought to go away in the future.  The only reason we
> track the current definition of a variable is for the old style
> of jump threading.  It should be possible to rewrite the code

What is the status of jump threading?

> which determines when a block has a threadable COND_EXPR which
> does not rely on maintaining the current definition of any variable.
> 
> The block local const_and_copies and nonzero_vars are trickier to
> make go away.

block_const_and_copies is roughly 200Kb of memory overall,
block_nonzero_vars just 33Kb, so these definitly can be dealt with
later.
> > > What needs to happen now is to expand that simple table of SSA_NAMEs
> > > to be a table of SSA_NAMEs and their global properties (for example
> > > their equivalences and nonzero status indicators).
> > 
> > How this is different from putting this directly into SSA_NAMEs?
> Not significantly so.  Though in general I don't like the idea of
> stuffing more crap into the tree structures.  

Well, technically the ssa_names table is also part of our IL, so we put
it there anyway.
I am not really fond of it either, but this is what we got into in the
past discussion.

Honza