Fix memory corruption in operands

[Jan Hubicka]

Hi,
 
> IIRC that after MEMSSA, this limit only gets hit by having a large
> number of global variables (or file level or whatever).  with MEMSSA
> before your changes, we didn't get that many very often (empirical
> collection from a bunch of large files), so I arbitrarily chose 128 as
> the point of diminished returns.  
> 
> With your changes, the limit or bucket sizes may very well need to be
> modified. I would expect to see more of that type of thing. This was
> just a first go untl we saw we needed something different.

I've checked and everything seems to work sort of as expected.  We
clearly inline more than we ought to (since our limits are still tuned
to expect unoptimized code), but retuning the limits should not change
behaviour that much.

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

Does some of this seem to make sense?
Honza
> 
> > I will investigate if everything in inliner is going as expected, but
> > overall this is pretty good thing to flatten the C++ abstraction and it
> > helps tramp3d considerably. (unfortunately tramp3d is only benchmark
> > exhibition such a noticeable benefit from the change and freefem3d
> > regress.  Not precisely what I hoped for, but retuning of inliner is on
> > the way).
> 
> And I expect re-tuning vop buckets may be required too since the
> underlying assumptions may well be different now :-)
> 
> Andrew
> 
>