Re: [PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3))

[Jeff Law <law at redhat dot com>]

[ Just a note, of this reply is meant for Michael and other parts for 
David, hopefully the audience is clear from the context. ]

On 11/06/13 21:56, David Malcolm wrote:
> On Wed, 2013-11-06 at 16:32 +0100, Michael Matz wrote:
> > Hi,
> >
> > On Tue, 5 Nov 2013, David Malcolm wrote:
> >
> > > Here's a followup patch which ensures that every gimple code has its own
> > > subclass, by adding empty subclasses derived from the GSS_-based
> > > subclasses as appropriate (I don't bother for gimple codes that already
> > > have their own subclass due to having their own GSS layout).  I also
> > > copied the comments from gimple.def into gimple.h, so that Doxygen picks
> > > up on the descriptions and uses them to describe each subclass.
> >
> > I don't like that.  The empty classes are just useless, they imply a
> > structure that isn't really there, some of the separate gimple codes are
> > basically selectors of specific subtypes of a generic concept, without
> > additional data or methods; creating a type for those is confusing.
>
> A type system does more than just express memory layouts:
> * it permits the proof of absence of certain bugs
Right.  As you have probably surmised, this is the single biggest thing 
we get from this work in my mind.  We use the type system to ensure a 
certain class of bugs simply won't get through the compilation phase.

That's a significant and important change from where we are now.  Right 
now we have no way of knowing that at compile time.  Instead we rely 
upon an insane set of macros to check this kind of invariant at run 
time.  Note carefully just because we don't hit a checking failure 
doesn't mean the code is safe.  It just means we haven't found a set of 
preconditions necessary to trip the problem at runtime.  Obviously in 
some (many), where may be no such way to trigger the failure, but 
there's no way to prove it.

Don't get me wrong the checking macros, when they were introduced were a 
godsend.  But they're papering over a fundamental problems in GCC's 
internal representations.

I think it's hard to overestimate the value we get by moving this stuff 
into compile-time type checking.


> I can post a followup patch that makes use of each of these, if it will
> help.
I wouldn't mind seeing a small example proof of concept posted to help 
those who don't see where this is going understand the goal.  I would 
recommend against posting another large patch for inclusion at this time.

Jeff