Re: Explicitly release memory used by varrays

[Jeffrey A Law <law at redhat dot com>]

On Mon, 2004-09-13 at 10:09, Jan Hubicka wrote:
> > On Thu, 2004-09-09 at 02:15, Jan Hubicka wrote:
> > > Hi,
> > > these varrays appears top in the list I sent, so I am adding code to
> > > release them explicitely.  This itself save roughly 3% of garbage
> > > produced on combine.c.
> > > 
> > > Bootstrapped/regtested ppc-linux, OK?
> > > 
> > > 2004-09-09  Jan Hubicka  <jh@suse.cz>
> > > 	* tree-ssa-dom.c (tree_ssa_dominator_optimize, dom_opt_finalize_block):
> > > 	Explicitly release varrays.
> > As I said, I would STRONGLY suggest you move this into the toplevel
> > SSA_NAME object rather than paper over the issue with ggc_free calls.
> > That will totally eliminate these two varrays, their resizing and
> > re-allocation for each call into the dominator optimizer.  That's
> > going to be a far more effective solution.
> 
> I have problems seeing how this can be more effective at least in 4.0
> horizont.
It's not that big of a change.



>   At the moment both varrays are just dominator opt local data
> (even tought it may change in future) and I don't see good reason for
> pollution and increasing the program representation by these.
Not really.  Both really are global data that need to be associated
with an SSA_NAME.  The fact that they are local to DOM is a design
mistake that needs to be corrected.


> I however went ahead and implemented your idea (WIP patch is attached).
> There is still some bug preventing bootstrap I am chasing down, but at
> least for combine.c compilation I can get exactly same dumps so I
> believe the tree-ssa-dom works same way as without my patch.
I was thinking this information would be better stored in the 
ssa_names array itself.  ie, it would be an array of structures
which described the properties of the SSA_NAME, much like we
have for REGs.  I'm not wed to that idea, though I tend to like
that more than expanding SSA_NAME tree nodes.

> I never seen these two varrays to be particularly expensive in the
> profiles - we allocate them just twice per program compilation and
> accesses are resonably effective.  In fact for datastructures local to
> optimization pass the array indexed by ids looks like perfectly sane
> datastructure to me.
?!?  We can allocate the global const_and_copies and vrp data
varrays many many times.

At a minimum we allocate them 3N times where N is the number of
functions we compile within the compilation unit.  In practice
the number can be significantly higher if DOM iterates due to
jump threading.

 

> I just looked on the most memory consuming varrays and decided to start
> with this one to test the approach and see if you like it.  In the case
> this patch seemed to be good way to go, I would continue on the others.
> I also did noticed this reuse scheme in tree-into-ssa but missed it here
> so it seemed like easier target than the tree-into-ssa varray.
Well, given that all of the block local varrays are just varrays of
trees, you could easily build a manager which kept of free
list of varray trees for reuse.  You would (of course) release all
of them when DOM completes.

I doubt it's worth the effort to do anything like sort them into
buckets based on their size.  ie, a simple cache of reusable
varrays trees ought to be enough to avoid creating tons of
garbage.

The existing scheme was implemented the way it is precisely to
avoid creating tons and tons and tons of block local varrays
for 8361 and a variety of other tests.
 

jeff