More memory reductions for DOM

[Jan Hubicka]

> Similar to the previous DOM patch, this patch moves a block local
> varray to a global varray.  This time it's avail_exprs.

Thanks again!
> 
> Unlike stmts_to_rescan, avail_exprs doesn't have a convenient way to
> map a particular entry in the varray to a block (which we need to
> facilitate unwinding).  So instead we push a null marker on the
> stack and unwind to the first null marker we see.
> 
> This reduces the number of varrays we create for unwinding the 
> expression table from > 9000 to 987 with roughly a 500k reduction
> in the amount of varray memory we allocate for Gerald's testcase.
> 
> I'll note that something added ~20M of GC allocated memory for
> Gerald's testcase in the last 24-48 hours (though compilation time
> seems to have noticably improved).  So any improvements I'm
> making in terms of memory consumption are probably being dwarfed
> by ongoing merging of queued development code.

This is actually why you can now look into gcc-regressions mailing list
and see reports of the memory consumption tester with quite good
granuality (the same machine runs also SPECs but it is fast enought to
test memory usage several times per a day)

The 20MB memory increase you see is probably the new aliasing code:
http://gcc.gnu.org/ml/gcc-regression/2004-09/msg00102.html
and we are just discussing what to do about it with Kenneth.
The cost of tree-ssa-dom.c is roughtly 120MB on the testcase tought, so
your improvements definitly have good chance to outweight memory
increases in this area :)

However your patch also didn't have any measurable positive effect
http://gcc.gnu.org/ml/gcc-regression/2004-09/
(the sbrk/mmap memory increase might be actually caused by fact that I do
measure it with ggc instrumentation enabled that has big memory overhead
itself - I will reconfigure the server to measure sbrk/mmap on checking
disabled compiler as soon as I find some time on it).

Is there any chance that you will either ggc_free the new big varrays on
the end of compilation, make them reused across different dom runs
or use the vectors with malloc allocation for them so we actually see
the benefits?  The savings on combine.c ought to be about 1%.

Honza