On 8/10/12, Diego Novillo <dnovi...@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