Varray memory consumption strikes back

[Jeffrey A Law]

On Sat, 2004-09-04 at 03:59, Jan Hubicka wrote:
> and the proposed patch to make varrays allocatable either in GGC and
> memory flag has been rejected and you mentioned to have better sollution
> in prototype stage (moving away from varrays to sane datastructures and
> improving them at the same time).
Well, I haven't had time to pick it up, but it wouldn't be terribly
hard for you to do so.  I would prefer reducing the amount of
varrays we carry around as opposed to bypassing our memory allocation
system design.

The first step is already done (by Diego), specifically we needed a
formal SSA_NAME table.  As I said, this is already done.

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).

Once you do that, the const_and_copies global varray disappears. 

The second (closely related change) is that value range propagation
(currently under development by Diego) needs to replace the very
limited form we have in dom, which causes the VRP_DATA varray to
totally disappear, along with the VRP_VARIABLES varray.  Again,
this range information needs to be stored in the SSA_NAME table
so that we don't just punt the problem into CCP.

[ Note that both CONST_AND_COPIES and VRP_DATA are grown as the
  number of SSA_NAMEs grow, which can lead to significant
  over-usage of varray space. ]

There's more that can be done, but kililng those two global varrays
would be a huge step forward and it's not a huge amount of work.

I can't emphasize enough how bad I think it would be to make
varrays allocable in multiple memory regions.

jeff