Hi guys!
I've been having sporadic conversations with both Diego and Rth regarding
tuples, and I wanted to sum up, and get others' opinions.
After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
to continue overloading trees will be more work in the long run than doing the
actual separation between tuples and trees. This business of "this is
a tree, but not really", includes far too much special casing. It seems it's
best to bite the bullet now and separate the data structures in one sweep.
Here are a few points that have been brought up, in no particular order.
* Statements should be something like:
typedef struct gimple_statement_d { ... } *gimple_stmt;
...to emphasize the fact that these are statements, not expressions, decls,
or the like.
* By extension, we will also need:
typedef struct gimple_expression_d { ... } * gimple_expr;
For example, PLUS_EXPR, etc. These will have location, btw.
Something like:
gimple_stmt
|
=
/ \
/ \
/ \
gimple_expr gimple_expr
| |
tree +
| / \
decl / \
/ \
/ \
gimple_expr gimple_expr
| |
tree tree
* Unfortunately, we're going to have to duplicate a lot of the functionality
we currently have for trees. For example, since STATEMENT_LISTs are used
before gimplification, we'll have to come up with the equivalent thing
for tuples (say, GIMPLE_STATMENT_LISTS).
* Currently we convert trees in place into gimple. This will have to
change, now that we have a different data structure to convert into.
I came up with a lot of stupid designs to make the gimplifier work,
in place, with tuples, none of which I'll bore y'all with.
Instead, Diego has saved my risible approaches, by suggesting we create
the gimple structures as we go, much like we create RTL in expand. This
means we won't have an iterative approach that leaves partially
gimplified structures, like we now have.
So... we should have an emit queue, much like we have an emit queue with
RTL. Each gimplifier function must emit individual gimple_stmts there,
so instead of calling buildN(), we call helpers that can emit the
associated gimple_stmts.
Yes, this means serious gimplify.c overhaul. And for some reason I've been
volunteered to do it. ;-)
Thoughts, ideas, 5k-line patches doing all the work?
Aldy
