Re: [tuples] Convert SSA rewriting (part 2)

[Andrew MacLeod <amacleod at redhat dot com>]

Diego Novillo wrote:
> On Jan 15, 2008 2:28 PM, Richard Guenther <richard.guenther@gmail.com> wrote:
>   
> > On Jan 15, 2008 10:41 PM, Diego Novillo <dnovillo@google.com> wrote:
> >
> >     
> > > - When statements are removed we were not freeing the operand
> > > structures.  This bug is also present in mainline, but the memory
> > > leakage shouldn't be too bad, so I'll wait for 4.4 to move this in.
> > >       
> > Not too bad?  Remember we have these testcases with unreasonable
> > amount of (virtual) operands.
> >     
>
> Not due to leakage.  Those are live operand vectors.  Still sticking a
> call to free_stmt_operands in bsi_remove may be worth trying.
>
>   

Well, calling bsi_remove() doesn't mean the stmt will actually be 
deleted. It means it will be removed from the stmt list, but  it may 
then be relinked in via bsi_insert* . 

I think general practice has been passing a 'true' as the remove_eh_info 
parameter implies the stmt will be deleted, so one might be able to try 
it there. I don't know if that is always true or not, it would have to 
be confirmed at each call site and then document it as such.

We'd also have to look for cases where false is passed, and the stmt is 
then chucked anyway. So its slightly more involved than just calling 
free_stmt_operands().

I'd be surprised if many of the stmts with a lot of virtual operands are 
physically deleted very often. Any operands which are not freed up this 
way will be freed when SSA is released and the entire operand pool is 
deallocated. So it doesn't stay lost for long. 

Who knows, maybe it does add up for a very large function, but I 
wouldn't expect it to be very significant in the grand scheme.

Andrew