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>]

On 11/08/13 12:02, David Malcolm wrote:
> > 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.
> Attached is a proof-of-concept patch which uses the
> gimple_statement_switch subclass (as a "gimple_switch" typedef).  This
> is one of the subclasses that the earlier patch added, which has no new
> fields, but which carries the invariant that, if non-NULL,
>     gimple_code (gs) == GIMPLE_SWITCH.
[ ... ]

Thanks.  It's pretty much what I expected.  Obviously for other codes 
there may be a lot more changes that you have to slog through, but I 
think this example shows the main concepts.

Presumably in this new world order, the various gimple statement types 
will continue to inherit from a base class.  That seems somewhat 
inevitable and implies a certain amount of downcasting (via whatever 
means we agree upon).  The worry, in my mind is how pervasive the 
downcasting will be and how much of it we can get rid of over time.

I may be wrong, but ISTM some of the downcasting is a result of not 
providing certain capabilities via (pure?) virtual methods.  For 
example, expand_gimple_stmt_1 seems ripe for implementing as virtual 
methods.   ISTM you could also have virtuals to build the statements, 
dump/pretty-print them, verify them, branch/edge redirection, 
estimations for inlining, etc.  ISTM that would eliminate a good chunk 
of the downcasting.

Just to be clear, I'm not asking you to make those changes, just for 
your thoughts on approaches to eliminate the downcasting based on what 
we've seen so far.

Thanks for pulling this together to help illustrate how some of this 
might look in practice.  I hope others take the time to look closely as 
this example and think about what it means in terms of how we would be 
writing code 6 months from now.


Jeff