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

[Lawrence Crowl <crowl at google dot com>]

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.

-- 
Lawrence Crowl