[cxx-conversion] Support garbage-collected C++ templates

On 12-08-09 09:05 , Richard Guenther wrote:

> What I do not understand is why you need a GTY(()) annotation on
> C++ types with user-defined gc routines.  gengtype should treat all
> types not marked with GTY(()) as having user-defined gc routines, no?

Ideally, yes.  But currently gengtype makes it hard to do because of the 
way it's designed.  When it finds a struct with no GTY() hooks, it 
completely ignores it.  If that struct is later reached from a ggc root, 
it is too late to say 'ah, it must be a user type'.

That's why if we add a keyword to indicate that this struct is 
user-handled, things start working (with some limitations).

In this patch, I implement this notion.  As an example, I modified 
struct edge_def.

The good:

- No GTY markers are needed for the fields of the structure.
- The user provides gt_ggc_mx and gt_pch_nx (2 variants).  These are 
implemented in terms of calls to gt_ggc_mx and gt_pch_nx (see tree-cfg.c).
- gengtype generates the generic glue that calls these functions.

The ugly:

- The structure needs to be marked 'GTY((user))' for the gty parser to 
put it in the list of interesting structures (most notably, it gives it 
a source location, which is the indicator used in the rest of gengtype 
to decide whether a structure is interesting).

- The user-provided markers need to declare the prototypes for the 
gt_ggc_mx and gt_pch_nx for the type fields.  This is due to the lack of 
prototypes generated in gtype-desc.h (or some other header).

These two warts are the ones I was referring to.  I need to fix these in 
trunk because they will require quite a bit of file reorganization.

The end point should be that the only thing we really need to tell 
gengtype about are the variable roots.  Everything else would rely on 
user-provided markings.  I suppose we could still keep the automatic 
option for really simple stuff, though.


Diego.


2012-08-10  Diego Novillo  <dnovillo@google.com>

         * basic-block.h (struct edge_def): Mark GTY((user)).
         Remove all GTY markers from fields.
         (gt_ggc_mx): Declare.
         (gt_pch_nx): Declare.
         * tree-cfg.c (gt_ggc_mx): New.
         (gt_pch_nx): New.

         * gengtype-lex.l (USER_GTY): Add pattern for "user".
         * gengtype-parse.c (option): Handle USER_GTY.
         (opts_have): New.
         (type): Call it.
         If the keyword 'user' is used, do not walk the fields
         of the structure.
         * gengtype.h (USER_GTY): Add.

On 2012-08-10 08:06, Diego Novillo wrote:
> The end point should be that the only thing we really need to tell
> gengtype about are the variable roots.  Everything else would rely on
> user-provided markings.  I suppose we could still keep the automatic
> option for really simple stuff, though.

Yes please.  Markup may be awkward, but I think can be less awkward
than generating those three cookie-cutter functions.


r~

On 12-08-10 16:14 , Richard Henderson wrote:
> On 2012-08-10 08:06, Diego Novillo wrote:
>> The end point should be that the only thing we really need to tell
>> gengtype about are the variable roots.  Everything else would rely on
>> user-provided markings.  I suppose we could still keep the automatic
>> option for really simple stuff, though.
>
> Yes please.  Markup may be awkward, but I think can be less awkward
> than generating those three cookie-cutter functions.

Yeah. Another thing I suppose we want to keep is the whole 'prev' and 
'next' markings. These generate harness that would be cumbersome to 
implement from user code.


Diego.

On 8/10/12, Diego Novillo <dnovillo@google.com> wrote:
> On 12-08-10 16:14 , Richard Henderson wrote:
> > On 2012-08-10 08:06, Diego Novillo wrote:
> > > The end point should be that the only thing we really need to
> > > tell gengtype about are the variable roots.  Everything else
> > > would rely on user-provided markings.  I suppose we could still
> > > keep the automatic option for really simple stuff, though.
> >
> > Yes please.  Markup may be awkward, but I think can be less
> > awkward than generating those three cookie-cutter functions.
>
> Yeah. Another thing I suppose we want to keep is the whole
> 'prev' and 'next' markings. These generate harness that would be
> cumbersome to implement from user code.

Diego and I talked about this issue.  What follows is sort of a
brain dump.  Corrections welcome.

There are several principles we can apply to the work.

   Data types that change frequently should be handled automatically.
   Otherwise, the purpose of precise garbage collection is somewhat
   defeated.  If we get to that situation, we should simply figure
   out how to convert the collector to something else.

   GTY markings that change frequently, or are hard to understand
   and get right, are a burden as well.

   The complexity of gengtype's implementation can be substantially
   reduced if it does not try to solve all problems.

   We are compiler engineers, and we can do complex manual work
   when appropriate.  Not everything needs to be automatic.

Applying those principles, we can reach some conclusions about
approach.

   We can rely on GTY((user)) for template class types.  By and large
   these types implement general data structures, like hash tables.
   The won't change much once built, and so maintenance of the manual
   marking routines will not be a large burden.  Taking this approach
   means that gengtype will not have to understand templates.
   We really do not want gengtype trying to understand templates.
   Diego has already implemented this part.

   Some types generic via void* and use param_is/use_param.  As we
   migrate to templates, much of these uses can go away.  Perhaps,
   eventually, we might be able to remove that complexity from
   gengtype.  As this possibility is closer to wishful thinking,
   it has really low priority.

   We cannot rely on GTY((user)) for class hierarchies that hold
   program structures.  For example, cgraph and tree nodes are too
   volatile to rely on manually synchronizing the marker function
   with the data fields.  So, we need to get gengtype to work with
   class hierarchies.

   We probably do not need to handle multiple inheritance.  First,
   existing structures do not use it.  Second, it probably would not
   be used much anyway.

   Polymorphic class hierarchies may require the user to add a
   couple of method declarations for gengtype.  Gengtype would then
   provide the method definitions.  We do not have any polymorphic
   classes yet, so this issue has a low priority.

   We will likely borrow the descriminator/tag structure of
   unions for the marking of non-polymorphic class hierarchies.
   Gengtype will split the marking of fields and the identification
   of the dynamic type into separate functions.  We have several
   non-polymorphic class hierarchies now, though represented with
   unions and embedding, so this issue has a high priority.

   Some current classes with nested unions, e.g. tree_type_symtab
   within tree_type_common within tree_node, might be convertable
   to a class hierarchy that eliminates all unions.  If so, they
   will likely need more than one descriminator. Given that such
   structures can persist with nested unions for some time, this
   issue has low priority.

Given all that, it seems that the highest priority for
gengtype modifications is direct support for non-polymorphic
single-inheritance class hierarchies that are discriminated by tags.