[rfc] Moving bbs back to pools

[Daniel Berlin]

On 6/7/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 6/7/07, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> > Hello,
> >
> > > Ian Lance Taylor <iant@google.com> writes:
> > >
> > > > Zdenek Dvorak <rakdver@kam.mff.cuni.cz> writes:
> > > >
> > > > > The problem is, that it does not give any speedups (it is almost
> > > > > completely compile-time neutral for compilation of preprocessed
> > > > > gcc sources).  I will check whether moving also edges to pools
> > > > > changes anything, but so far it does not seem very promising :-(
> > > >
> > > > Does it make any difference for gcc.c-torture/compile/20001226-1.c?
> > > > And of course it won't make any difference if you have enough memory
> > > > that you never need to garbage collect without your patch.
> > >
> > > I was wrong to say that.  It could make a difference even if you don't
> > > garbage collect, since the allocation will be cheaper.  But that is
> > > likely to be a relatively small effect.
> >
> > actually, the expected speedup was mostly supposed to come from better
> > locality.  The speed of garbage collection should be about unchanged.
> > Regarding the speed of allocation, pool_alloc might be slightly faster,
> > but probably not significantly.
>
> Uh, structures as big as basic_block won't get better locality by placing
> them near each other.  But maybe I'm missing something ;)

They did when we took a couple percent slowdown from moving them to
GC. See the patch that did it :)

Though i think they were smaller then :)

Edges were also pool alloc'd, and i believe both were switched at the
same time, so it's possible the locality came from the edges.