IPA merge part 1: localize SSA variables

[Andrew MacLeod]

On Wed, 2006-11-15 at 17:54 +0100, Jan Hubicka wrote:

> > >! #define free_defs (cfun->ssa->x_free_defs)
> > >! #define free_uses (cfun->ssa->x_free_uses)
> > >! #define free_vuses (cfun->ssa->x_free_vuses)
> > >! #define free_maydefs (cfun->ssa->x_free_maydefs)
> > >! #define free_mustdefs (cfun->ssa->x_free_mustdefs)
> > >! #define free_ssanames (cfun->ssa->x_free_ssanames)
> > >! #define operand_memory (cfun->ssa->x_operand_memory)
> > >! #define operand_memory_index (cfun->ssa->x_operand_memory_index)
> > >  
> > Likewise here.  Why is it that you need to privatize these caches?  I
> > don't think I followed your reasoning.
> 
> There was problems with the operand cache freeing and changing the
> context in twisted way.  I can probably split this up, do grand
> 
twisted? :-)

All the operand cache does is allocate blocks of memory as needed and
sub-allocate operands from there.  When we don't need the cache any
more, it simply frees all the large blocks at once.  Its effectively a
private zone collector for 5 data types.

This would need to be local to each function as it stands today. You
could make it global to all functions easily enough by simply not
freeing those blocks until there is NO operand cache required (add a
counter to init/free_ssa_operands() so you know how many functions are
currently using it.

I'm not sure which way would be better. You'll likely get slightly worse
cache performance if its global, but you will get better free list
utilization.


> substitution up to operand caches first and deal with operand caches in
> subsequent patch.  Once I did shared caches on the IPA branch, but the
> subsequent changes to the mainline into tree-ssa-operands forced me to
> revert that part, this should not be problem after merge, of course. But
> it definitly needs some not completely obvious changes.

I'm not sure what that would be, it isn't ding anything especially
tricky.

Andrew