Re: Tuples for GIMPLE

[Mark Mitchell <mark at codesourcery dot com>]

Diego Novillo wrote:
> A few days ago we had chatted with Ian on IRC about the general idea of
> using some tuple-like structure for GIMPLE instead of the current notion
> of treating everything as a 'tree'.  We also chatted briefly with Zdenek
> about this when he proposed turning compiler temporaries into non-decls.
>  I think all these threads are converging and we should probably start
> doing something about it.

I've been thinking about this in the back of my mind as well.  I think
we're all agreed that everything-is-a-tree is not what we want, and that
this kind of "tree trimming" is a good idea.

> modify_expr     =   4770176 ( 75%)
> label_expr      =    860960 ( 13%)

Very nice.  That does tell us a lot.

My initial suggestion for a first angle of attack is:

1) Reorder tree_common so that the "code" and bitfields are first.

2) Redefine tree_common as:

struct tree_base {
  enum tree_code code:8;
  /* flags */
};
struct tree_common {
  struct tree_base base;
  tree chain;
  tree type;
  union tree_ann_d *ann;
};

3) Define a SSA_MODIFY_EXPR as follows:

struct tree_ssa_mod_expr {
  struct tree_base base;
  /* operands */
};

4) Adjust TREE_TYPE, TREE_CHAIN, etc. to fault when operating on an
SSA_MODIFY_EXPR.  (Or, have them return NULL_TREE.  Or, perhaps, you
want TREE_TYPE to return void_type_node or the type of the operands, for
convenience?)

5) Allocate SSA_MODIFY_EXPRs, not MODIFY_EXPRs, for SSA.  Fix all the
assertions. :-)

The reason I'd keep tree_base is that you presumably need some kind of
tag to tell you what you've got anyhow.  So, you're wasting at most one
word, rather than the current four, and you can still leverage some of
the existing machinery.

The more radical approach would just be to define a completely new
family of nodes for SSA form.  That would allow you to drop the
remaining word. I'm not sure how much harder that would be, if any; it
might be that the "radical" solution is no more work.  However, the
suggestion above means that you can convert MODIFY_EXPRs without
converting the other things pointed to by a SSA statement, since they
are still trees, at least to the point of having a tree_code.  Then,
once everything had an SSA_<foo> form, the conversion to
not-trees-at-all would be easy.  The other nice thing about the less
radical approach is that it might let us start incoporating the leaner
trees into the rest of our IL; we'd start having the idea of
trees-without-a-TREE_CHAIN.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713