Re: IPA merge part 1: localize SSA variables

[Jan Hubicka <jh at suse dot cz>]

> 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.

I do agree that malloced memory is cheaper (and I've missed the fact
when looking at it today).  My current plan now is to simply localize the
other stuff and then localize the caches in incremental patch pretty
much as I did in the original (modulo the accessors).
>  
> > 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)

Well, what I did is to call function on the statement in function
different from cfun. That function asked for operands and initialized
the cache from wrong cfun.  Accessors themselves won't save me here.
What we need is to push function argument into all the gimple
infrastructure that might be used by IPA passes (most of it), that will
probably take some time and gradually eliminate many/most of the global
cfun variable references.
> 
> 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. 

Yep, we can do some fine tweaking once the changes are done and we see
how the whole thing behave.

Honza
> 
> 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
> 
>