This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IPA merge part 1: localize SSA variables


> 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? :-)

In my mind yes, your operand cache rewrites was one of foremost reason
for mainline merges to IPA branch not bootstrapping  ;) But this was
just bad luck here combined with fact that operand scan was one of most
actively developed part of the bits I touched with IPA. Looking at the
current implementation, it seems quite straigforward to me now.
> 
> 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.

With the scheme of turing all functions into SSA first and compiling
individual bodies later, having counter probably won't get us much as it
will drop to zero with last function compiled, right?
> 
> 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.

I am quite undecided here.  I think having the freelist in GTY deletable
blocks global across all functions should be quite easy to do and most
consistent with other code.  Do you se any problem with this scheme?
Doing the per-function caches has the disadvantage of little extra
cfun->df memory needed and the risk of somehow using wrong freelist as I
did in past.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]