tuples: data structure separation from trees

[Aldy Hernandez <aldyh at redhat dot com>]

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