IPA merge part 1: localize SSA variables

[Andrew MacLeod]

On Wed, 2006-11-15 at 18:49 +0100, Jan Hubicka wrote:
> > On Wed, 2006-11-15 at 17:54 +0100, Jan Hubicka wrote:
> > 
> > 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?

the reason it has its own memory management is because it is very
heavily used (lots of freeing/allocating), and it drove the garbage
collector nuts, consistently getting slower times on large functions. I
did a lot of timings and tweaking. 

At best, you could put the large allocated blocks in GTY memory, but
that doesnt buy you much since every suballocation in the block would
have to be freed in order for the large block to be free. Its just a lot
of extra things for the GC system to sort through. If you do decide to
go global, I would still leave it as malloc'd blocks simply because the
operand cache never, ever, mixes with anything else, so keeping it
distinct in its own 'zone' seems quite sensible and its hard to be more
efficient.
 
> 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.

If everything is accessed via accessors like "blahblah (cfun)"  you
shouldn't have the problem of using the wrong freelist :-) (and I
completely agree that is the way to go , btw)

I suspect the tradeoff between per-function cache and global will
probably be a wash. Leaving it local is simpler for now, for whatever
that is worth. 

One could argue that the operand cache really is local to a function.
Its not required for SSA correctness or anything, so in theory you can
store an SSA function without the operand cache, and rebuild the cache
later if you ever needed it again.  There may be some possible benefits
of that down the road.


Andrew