Re: [tree-ssa] Reduce resizing of PHI nodes, create less garbage

[law at redhat dot com]

In message <20031203222801.GB9956@redhat.com>, Richard Henderson writes:
 >On Wed, Dec 03, 2003 at 11:56:33AM -0700, law@redhat.com wrote:
 >> +    Rounding up will not result in wasting any memory since the size reque
 >st
 >> +    will be rounded up by the GC system anyway.  [ Note this is not entire
 >ly
 >> +    true since the original length might have fit on one of the special
 >> +    GC pages. ]  By rounding up, we may avoid the need to reallocate the
 >> +    PHI node later if we increase the number of arguments for the PHI.  */
 >
 >I'd be interested in you re-evaluating your analysis with the zone
 >allocator.  In particular, gone are the "size pages" from the current
 >default allocator.
 >
 >I'd hate for you to spend lots of time tuning this code for one GC
 >implementation only for us to replace it out from under you.
Well, if you replace it with the zone allocator, you still don't want to 
be doing 80k PHI resizings -- that's ultimately wasteful no matter what
allocation scheme is underneath.

So I expect you'll still want the manager to do some kind of bumping-up of
the initial requested PHI lengths.   The exact details of how much we increase
the initial request might change since we don't have GC pages where we can
increase "for free".  Then again, the details of how much we increase may
not change significantly.  It's hard to tell at this point.

I'm not planning on further tuning of that code.  The only thing I've pondered
is a callback to the allocator (whether it be malloc, GC or zone based) which
given some allocation size X returned Y, a possibly larger allocation size
which was more friendly for the allocator to manage.  I ultimately didn't
add that capability as my suspicion is that it's over-engineering for what
we need.

Jeff