Re: Fix memory corruption in operands

[Andrew MacLeod <amacleod at redhat dot com>]

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

> > 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.
> 
> Good, so we take care to remove operands of all dead statements and put
> them back to freelist, right?

as long as the annotation is freed, they end up in the free list. Right
now, we never lose anything in a function because when we free SSA,
*all* the pointers to operands are allocated from the memory chunks
which are managed by the operand cache. At the point, even if we had
lost the handle to some of the memory via stray annotations that got
lost, freeing the cache up still makes the memory go away for the
operand cache.  

you will of course lose that if you go to a global list because the
cache will never be freed up until the last function is processed.  It
boils down to how well we manage the annotations. As far as I know, they
should be handled reasonably well.  If we don't, They certainly should
be anyway :-)
 
At least I believe that to be true. Hmm.  Perhaps we better verify
it :-)  We definitely manage it properly when operands are updated  by
the cache routines.


> > 
> > 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... 
> 
> Yes, I simply do update_stmt after copying the statement expecting
> operand scanner to build operands for it, followed by regular update_ssa
> to fixup some special cases where I don't produce SSA form, but direct
> VAR_DECLs.  We don't have aliasing built, so at the moment we don't have
> virutal operands really at this level.
> I am evaulating posibility to build aliasing.  Early results show about
> 100MB memory increase on tramp3d that is not _that_ bad.  But I still
> can't compile non-trivial testcases so I don't know what the final
> outcome might be.

I would actually have expected the virtual operands to chew up more
memory than the real operands.  How much memory do the operands consume
on tramp3d? perhaps we aren't freeing enough stuff from the
annotations...

Andrew