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