Re: [tuples] code checking for tree expressions

["Daniel Berlin" <dberlin at dberlin dot org>]

On 9/25/06, Aldy Hernandez <aldyh@redhat.com> wrote:
> Hi Richard.  Hi Diego.
>
> Could you please take a look at this patch, and tell me if you agree with
> the style and decisions?
>
> Apart from the usual mundane changes, this patch addresses code that depends
> on tree expressions (through EXPR_P and IS_EXPR_CODE_CLASS).  Most of these
> places need to include gimple statements.  I didn't know whether to come
> up with a new macro, or just "||" away, like I'm currently doing.  The
> present code was ad-hoc, so I tried to keep it that way.
>
> Tangentially related is a new macro CAN_HAVE_LOCATION_P which I had to
> define to differentiate between a node that has an actual location
> (EXPR_HAS_LOCATION) and one that can have one (like expressions ala
> EXPR_P and gimple statements).

Just as an example, the way I handled this situation when reworking
the DECL structures was to just come up with a way of saying which
tree codes contained which substructures.
IE that PARM_DECL has a "struct tree_common" and a "struct
tree_decl_with_rtl" in it.

This is used to implement things like:

/* Returns nonzero if NODE is a tree node that can contain RTL.  */
#define HAS_RTL_P(NODE) (CODE_CONTAINS_STRUCT (TREE_CODE (NODE), TS_DECL_WRTL))

That allows us to tell which nodes you can use DECL_RTL on, without
having to explicitly || all the codes at each point you want to use
the macro, and then update every single place when someone adds a new
tree node or tree structure.

If you forsee this kind of structure inheritance being used in the
GIMPLE tuples (whether for statements or not), you should probably
just fill in the tree_contains_structure array and some structure
codes and use that.