Re: RFC: GC allocating everything with a type, part 1

[Geoff Keating <geoffk at geoffk dot org>]

Steven Bosscher <stevenb@suse.de> writes:

> There are at least two types that need to be special-cased (perhaps more,
> but I haven't found them yet -- but probably not many).  These are the
> types that do not have a fixed size, such as our core types, the unions 
> rtx_def and tree_node.  The macros for these types accept an extra SIZE
> argument as follows:
> 
> #define ggc_alloc_tree_node(SIZE) \
>   ggc_alloc_typed(gt_ggc_e_9tree_node, SIZE)
> 
> and
> 
> #define ggc_alloc_rtx_def(SIZE) \
>   ggc_alloc_typed(gt_ggc_e_7rtx_def, SIZE)
> 
> I want these defines to be generated automatically, and the only way I
> could think of to tell gengtype about these special cases is by adding
> an extra GTY parameter, "size_not_fixed".  That's a bit ugly, if people
> have other suggestions then let me know please.

My preferred solution is to have a parameter that gives the size of
the object; if the parameter is not provided, it defaults to sizeof().
You couldn't use it in the macros, since you're going to need to read
the object in the parameter, and you don't have one before you
allocate it; but the presence of the parameter would indicate that the
allocation macro can't just use sizeof().  (The actual conte

This would also allow you to avoid the need for ggc_get_size.  I was
originally going to implement this for PCH, but ggc_get_size was
available, so that was easier.

> There also is some work to do for types that take the GTY param_is and
> param[0-9]_is attributes.  Right now we use them for one varray (since
> Geoff's patch from two days ago) which is easiliy fixed, a number of
> hashtables, and two splay trees.  On other words, rare cases that we
> just need to think up something special for.

These cases aren't *that* rare.  There are 18 different parameterised
types in my build.

> (Fortunately most hash tables are for trees, so we can hide all magic
> in another #define we can put in by hand in ggc.h or something.

I think your 'most' is wrong.  My quick survey says that 4 of 13 GCed
hash tables in gcc contain just trees.

>  For the
> others it probably means passing around the type codes.)

The real problem is that these aren't allocated inside GCC, so
#defines are irrelevant; you'd have to write special allocator
routines that can be passed to htab_create_alloc and
splay_tree_new_with_allocator.

I recommend you instead ignore the parameters, and treat all hash
tables, splay trees, or whatever the same.  If you have the typecodes
stored with each allocated object, you don't need to know in advance
that this is a 'hash table of constant_descriptor_tree'; you just need
to know it's a hash table, and if you need to know the type of a
particular element, you can just go look.


However, there's another problem you've not noticed yet.  Consider
struct emit_status in function.h.  It contains the following field:

  rtx * GTY ((length ("%h.x_reg_rtx_no"))) x_regno_reg_rtx;

What type are you going to give to the object that this field points
to?  You need to mark it, it contains pointers to rtx; but you don't
even know how many of them there are without looking at the containing
structure.  So you'll need to keep a back pointer.

-- 
- Geoffrey Keating <geoffk@geoffk.org>