On Mon, Apr 19, 2010 at 4:43 PM, Laurynas Biveinis <laurynas.bivei...@gmail.com> wrote: > Hi, > > Now that GCC is in the stage1 and gc-improv branch work is finished as > I see it, I propose to merge it to mainline. > > The goal of the branch is to make the type of GC-allocated objects > known to GC at allocation time, by changing the allocation interface > from > foo *x = (foo *)ggc_alloc (sizeof (x)); > to > foo *x = ggc_alloc_foo (); > > Having this enables further work on GC. Note that it has been prototyped > before: > http://gcc.gnu.org/ml/gcc/2004-01/msg01081.html > > It should not cause any changes in the compiler behavior whatsoever > (except some ggc-zone fixes, see below), except perhaps that > GC-to-obstack changes might improve data locality by a tiny epsilon. > > It comes with a few free extras: > 1) Completes the ggc_alloc* to GGC_NEW* interface transition by moving > away from both. > 2) Partly fixes zone allocator, especially in the presence of PCH. I > am content with "partly" here as I didn't break it and apparently > nobody uses it anyway. > 2) It shakes out a few places where GC shouldn't have been used in the > first place, replaced with obstack allocation. > 3) A few ggc.h and gengtype cleanups. > > A few points of note: > 1) For some types (tree, rtx) it is required to specify allocation > size explicitly. I have introduced a new GTY attribute variable_size > for that. > 2) To handle param_is options, libiberty needs to know how to allocate > using GC interface. Thus I have extended a few libiberty functions to > accept additional memory allocator callback parameters. > > So, if this work is accepted in principle, I will submit to mainline as > follows: > > First the independent parts, which are beneficial without the rest > merged. I will submit them shortly. > > 1) In the loop optimizer, move from GC to obstrack the types struct > lambda_loop_s, lambda_body_vector, lambda_matrix, lambda_trans_matrix. > Needs loop maintainer review. > 2) In the C parser, use obstack for braced initializer list parsing, > moving structs constructor_range_stack, init_node out of GC. Needs C > frontend maintainer review.. > 3) Debugging dump of the structures that gengtype builds and some > minor gengtype cleanups. Right now it is a debugging aid, later it > could be used to do gengtype dump/load that Basile wants for plugins. > Needs global maintainer review. > > And the merge itself. None of the following makes sense without the rest. > > 1) New API in libiberty for creating of hash tables and splay trees > with user-specified callbacks for allocation. Needs libiberty > maintainer review. > 2) Make gengtype accept variable_size GTY option and output typed GC > allocators to gtype-desc.h. Needs global maintainer review. > 3) Split ggc.h into ggc.h and ggc-internal.h, introduce internal > interface for gengtype output to use, fix MEM_STAT accounting, partly > fix zone allocator, partly fix zone allocator interaction with PCH, > and related minor ggc-*.c and stringpool.c changes. It is basically a > ggc.h rewrite from scratch. Needs global, or, I dunno, middle-end > maintainer review. > 4) Annotate several types with variable_size option. Needs all the > front-end maintainers' and middle-end maintainer review, or, maybe > easier, global maintainer review together with the next patch. > 5) Change all the allocation sites. Touches all the frontends, > significant parts of middle ends, and probably all the backends too. > The changes here are mechanical, so it would be easiest to get a > global approval from a global maintainer instead of specific area > maintainers. > 6) GTY documentation update in GCC internals manual. > > Comments? Thanks.
Sounds good to me. With a typed interface we should know the alignment requirements of allocations and so can pack objects tighter - do your patches already do that? Basically we pad any object larger than 8 bytes to multiples of 8 bytes even for say objects of size 12 bytes which wastes 50% of the storage as we do not know whether 4 byte alignment is enough. Thanks, Richard. > -- > Laurynas >
