Re: [tree-ssa] Avoid nondeterminism in tree-ssanames

[law at redhat dot com]

In message <1070320448.32256.130.camel@p4>, Andrew MacLeod writes:
 >Yeah, but I dont think you'll see much measurable difference in those
 >cases. Typically I suspect the kind of place you'll really see a
 >difference is when you have a multi-dimensional array indexed by
 >SSA_NAME version number. This is the case with the conflict graph in
 >SSA->normal.
Depends on how many of them you allocate, particularly varrays based on
the highest SSA_NAME :-)

 >> OK, what about delaying this thread until we can actually free the
 >> arrays allocated by GGC so we see how the situation behaves in practice?
 >> It seems to me that any benchmarks done right now are not very acurate
 >> and without benchmarks it does not make sense to try to discover complex
 >> sollutions :)
 >> 
 >Yes, much of these things are in fact moot if we get the GC fixed to do
 >what we need.
Well, "fixing GC" isn't going to make any significant difference on this
issue.  Fundamentally, we have an index which grows, sometimes unnecessarily.
The ability to reclaim memory space and such doesn't touch that problem at all.

 >So what are we doing to the GC?  Are we fixing the zone collector so we
 >can allocate pages to specific purposes?  And will there or will there
 >not be a free list mainatined within the zone?
Thinking more about these problems, we may still want a manager to handle
allocation of these objects on a per-function basis, then release all
the nodes back to the GC system en-masse, possibly using a zone allocator.

As Geoff said, it's likely going to be more efficient to maintain a freelist
than to release/re-allocate things like SSA_NAMEs, PHI_NODEs and the like
using the GC system.

 >I've abstracted out the use and def operands, Im going to make it work
 >for vuse and vdef operands as well. These seem like very likely
 >candidates for a zone as well, if it includes a free list, and can
 >handle small allocations easily. I've got a quick and dirty one that I
 >was going to provide with the abstraction which is very specific, but
 >efficient.  If GC will provide what I need, I wont worry about it.
I think a ggc_free is something we simply must have.  The question is
how efficient will it ultimately be.  There's a goodly amount of bookkeeping
necessary to free a single object in the GC system.

jeff