This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: Martin Jambor <mjambor at suse dot cz>, Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 4 Sep 2013 16:09:11 +0200
- Subject: Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
- Authentication-results: sourceware.org; auth=none
- References: <1377793216-22549-1-git-send-email-dmalcolm at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1308301532490 dot 9949 at wotan dot suse dot de> <1377890482 dot 29222 dot 32 dot camel at surprise> <20130902123533 dot GA23002 at virgil dot suse> <1378257610 dot 18117 dot 48 dot camel at surprise>
> On Mon, 2013-09-02 at 14:35 +0200, Martin Jambor wrote:
> > Hi,
> > On Fri, Aug 30, 2013 at 03:21:22PM -0400, David Malcolm wrote:
> > > Apart from the GTY aspect, how do people feel about the patch series?
> > > FWIW I have vague thoughts about doing something similar for tree -
> > > doing so *might* give an easier route to the type vs expression
> > > separation that Andrew spoke about at the Cauldron rearchitecture BoF.
> > > (I started looking at doing a similar C++-ification of rtx, but...
> > > gahhhhh)
> > >
> > I like it but before you start looking at the biger things, could you
> > perhpas proceed with the symtab? It has much fewer classes, will
> > probably affect private development of fewer people, the accessor
> > macros/functions of symtab are less developed so it will immediately
> > really make code nicer, Honza has approved it and I'm really looking
> > forward to it. Also, perhaps it will show us at much saller scale
> > potential problems with the general scheme.
> Sorry about the delay. I wasn't aware that it had been approved; there
> seemed to be a lot of caveats and objections in that thread. On
> re-reading, http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01147.html
> could be seen as approval, but I guess I was making a conservative
> reading of that post. I hope to refresh the patches and
> reboostrap/repost them at some point this week.
I think the patch was generally in right direction. I would welcome
if you got rid of symtab_node_base (and made symtab_node the basetype)
and possibly also did the suggested grand renaming. But the second
can be probably done incrementally.
> > I'm only writing this because the development there seems a bit
> > stalled and it it a shame. Of course, you ay want to simplify the
> > manual markings first. I'd perfectly understand that.
> I've been poking at gengtype (and running benchmarks; see other post),
> which would affect the symtab patch, though it's something of a
Making gengtype to generate ggc_mark for each type would make hand writting
easier - you can use C++ overloading instead of trying to guess the funny
names gengtype uses right now.
But that is independent of this change. I am slowly getting used to the
world of hand written gengtype markings.