[PATCH 0/6] Convert gimple to a C++ class hierarchy

[Richard Biener]

Jakub Jelinek <jakub@redhat.com> wrote:
>On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
>> > Well, it was a wrong decision then.  For some smaller types writing
>manual
>> > marker might be a sensible thing, or for some extra complicated
>> > constructs.  But here we're talking about the most simple struct
>hierarchy
>> > imaginable.  Having to write manual markers for that one is absurd
>IMO.
>> 
>> I want to discourage extending gengtype more than necessary. Long
>> term, I would like to see memory pools replacing GC. However, that is
>> likely a long road so we should find an interim solution.
>
>I have doubts that, still somewhat remember the obstack era and memory
>pools
>would again bring all the issues back, but let's put that aside.
>
>> I vaguely remember thinking about what would be needed to have
>> gengtype deal with inheritance. It needed some pretty ugly
>> annotations. This made gengtype even more magic.  That's very bad for
>> maintenance.
>
>Teaching the gengtype parser about
>{struct,class} name : public {struct,class} someothername { ... }
>as opposed to current
>{struct,class} name { ... }
>shouldn't be that hard.  And, if the complaint is that we'd need to
>write
>whole C++ parser for it, then the response could be that we already
>have
>one C++ parser (and, even have plugin support and/or emit dwarf etc.).

Note that explicit markings was also about simply writing GTY((derivesfrom(xxx))) instead of extending the parser.  The result could be as simple as gengtype emitting

 ggc_mx ((xxx) *this)

In the marker routine.

Richard.

>So, gengtype could very well use a g++ plugin to emit the stuff it
>needs,
>or parse DWARF, etc.  And, we even could not require everybody actually
>emitting those themselves, we could check some text form of that
>(gengtype.state?) into the tree, so only people actually changing the
>compiler would need to run the plugin.
>
>> One thing I liked is a suggestion that went something along the lines
>> of creating some base templates that could be used to facilitate
>> writing the manual markers.
>
>Even if you have some stuff that helps you writing those, still it will
>be a
>big source of bugs (very hard to debug) and a maintainance nightmare.
>
>	Jakub