This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Plan for gc-improv merge
Laurynas Biveinis 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 ();
Will the name of the marking routines, such as gt_ggc_mx_tree_node for
tree, change?
The MELT branch needs to know them (but can adapt easily to a name
change). And any other plugins using PLUGIN_GGC_MARKING probably wants
to know the naming convention (& the signature) for the marking routine,
so we might also document it.
Also, I believe that
foo* y = ggc_alloc_foo ();
should behave like the 4.5.0
foo* y = (foo *)ggc_alloc_cleared(sizeof(foo));
that it, that it should *clear* allocated memory. Clearing memory is
cheap, and allocating uninitialized memory could lead to hard to find bugs.
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.
How is that handled by their ggc_alloc_tree? As a size argument?
Also, it would be nice if the new ggc.h could define some preprocessor
flags specific to the change, eg #define GGC_ALLOC_IS_TYPED 1, to enable
coding plugins which could work on both 4.5 & 4.6
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:
I like it very much...
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.
It is hopefully not only me. As Diego wrote once, the current gengtype
for plugins is quite a hack, and we need to improve that.
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.
Yes, these are important, especially since the plugin interface expose a
bit more of ggc.h ...
Thanks for the good work!
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***