Fix memory corruption in operands

[Andrew MacLeod]

On Sun, 2007-01-21 at 04:08 +0100, Jan Hubicka wrote:
> Hi,

> One problem I wanted to draw into your attention is the memory
> consumption of datastructures associated with operands.  With
> --post-ipa-mem-report we can now get footprint after all are transfered
> to SSA and before we release function bodies of compiled functions (that
> will become critical for LTO).  In this footprint the tree-ssa-operands
> is major consumer.
> 
> I was thinking on several things we can reduce memory usage by"
> 
>  1) Currently we allocate operand caches per-function basis.  Since on 
>     tramp3d we redlete about 90% of statements during early cleanups, I
>     would expect about 90% of the memory do be dead.  Can we have just
>     one global freelist cache for all functions?  (it would probably
>     have problem if we are leaking some unused operands unfreed, but
>     that is bad anyway)
> 
>     If this fails for some reason, perhaps we can simply drop all the
>     operands memory after early cleanups and rebuild them, but it is bit
>     zelaous way of doing so.

I think we discussed being able to use the free-list in a global way
back when you were doing the initial file conversions. There is no
reason that can't be done.   

we shouldn't be leaking any operands, it should be an enclosed system.

Operand rebuilding is also easy to do if it comes to that. Real operands
can certainly be rebuilt very quickly.  Question. When you inline a
function, and there are virtual operands, do you have to do update ssa
on those newly inlined stmts?  I assume so, which means you are in
effect rebuilding the virtual operands on those stmts as well aren't
you?   If that's the case, you might be better off dumping the operand
cache anyway... 

>  2) The annotations are big too.  Perhaps we can mix all
>     vuses/uses/defs/vdefs into one vector and modify iterators to simply
>     skip ones of different type?  At least for uses+vuses/defs+vdefs mix
>     it should work pretty well, since numbers of real operands are
>     limited

I originally did some experiments with that type of thing (one vector
with indexes or pointers into it, and there were some unpleasant compile
time implications, IIRC, as well as some other issue I forget.  I could
revisit it again if it turns out to be a big issue. 

>  3) Danny observed that addresses_taken is computed by by
>     tree-ssa-operands just to be used on one place and just after
>     recomputing the statements operands.  Perhaps it can be dropped
>     completely and maintained just one per operands computed on demand?

This is Diego's stuff I think, he's best able to comment on that.

>  4) loads/stores bitmaps can probably be merged into one bitmap (by i.e 
>     encoding for even/odd numbers) or even move into on-side hash since
>     they are usually not set.
> 
More of Diego's mem-ssa stuff :-) I beleive those bitmaps were a bit of
a pox to him as well. We had discussed ways of saving memory by hashing
the bitmaps to return a single value which would get used by the stmt.
This would allow sharing of common bitmaps and reduce the memory
footprint. We discussed other possibilities as well, but I don't think
he has gotten to any of them yet.




Andrew