Re: RFC: gimple tuples data structures design

["Steven Bosscher" <stevenb dot gcc at gmail dot com>]

On 6/9/06, Aldy Hernandez <aldyh@redhat.com> wrote:
> Still missing are labels and gimple temporaries, but this should get the
> ball going.

For labels, do you need more than just the label decls?  We have
labels as statements in the statement stream now, but there really
isn't any reason for that AFAICT. You could just hang labels as
declarations from the basic blocks they are in (in a vec or a list or
something like that).

For gimple temporaries, are you planning on something different from
the current minimal decl (tree_decl_with_vis in tree.h; needs
re-indenting btw...)?

> /* All tree structures, including the gimple IL, derive from this base
>    structure.  */
> struct tree_base GTY(())
> {
>   ENUM_BITFIELD(tree_code) code : 8;

This will almost certainly be too small.  With ObjC we already almost
have more DEFTREECODEs than MAX_TREE_CODES.  Maybe make this 16 bit
while you're changing things in this area?

>   unsigned side_effects_flag : 1;
>   unsigned constant_flag : 1;
>   unsigned addressable_flag : 1;
>   unsigned volatile_flag : 1;
>   unsigned readonly_flag : 1;
>   unsigned unsigned_flag : 1;
>   unsigned asm_written_flag: 1;
>   unsigned nowarning_flag : 1;
>
>   unsigned used_flag : 1;
>   unsigned nothrow_flag : 1;
>   unsigned static_flag : 1;
>   unsigned public_flag : 1;
>   unsigned private_flag : 1;
>   unsigned protected_flag : 1;
>   unsigned deprecated_flag : 1;

Why the deprecated flag here?  Isn't this something language specific?
And many of these flags only apply to declarations, no?  I know we
heavily overload these bit flags for various purposes, but that's not
exactly one of gcc's aesthetic sweet spots. You're going to end up
adding members to most of the structures you describe below (e.g. to
encode some language semantics in a language-independent way for the
mixed-language LTO representation). Maybe you could move some flags
now already?

>   unsigned invariant_flag : 1;
>
>   unsigned lang_flag_0 : 1;
>   unsigned lang_flag_1 : 1;
>   unsigned lang_flag_2 : 1;
>   unsigned lang_flag_3 : 1;
>   unsigned lang_flag_4 : 1;
>   unsigned lang_flag_5 : 1;
>   unsigned lang_flag_6 : 1;
>   unsigned visited : 1;
> };
>
> /* This structure is for generic trees.  */
> struct tree_common GTY(())
> {
>   struct tree_base base;
>   tree chain;
>   tree type;
>   union tree_ann_d *ann;
> };

So there is still chain and type here, that's too bad. Ceaning that up
is outside the scope of your project I suppose.

But seeing GTY markers and TREE_CHAIN... There is no TREE_CHAIN or
another statement link in struct gimple_stmt, so you have nothing to
put a GTY chain_next and chain_prev marker on. I wonder how you plan
to make GC marking of gimple_stmts fast and not eating up the stack
due to recursion of the ggc marker functions?  Will these gimple_stmts
be in containers like struct tree_statement_list_node (which does have
chain_{next,prev} GTY markers)?

> /* Gimple statements.
>
>    This includes modify statements (what GENERIC calls MODIFY_EXPR),
>    labels, calls, gotos, etc, as well as OpenMP directives.  */
> struct gimple_stmt GTY(())
> {
>   struct tree_base base;
>   source_locus locus;
>   struct tree_base *operands[1];
> };

> /* Gimple SSA names.
>
>    This is the similar to ``tree_ssa_name'' in GENERIC

Why would we have tree_ssa_name for GENERIC?

> except
>    we save a `tree_ann_d', and a `type'.  We also move `ptr_info'
>    and `value_handle' to on-the-side arrays indexed by SSA names
>    (or hash tables).  */
> struct gimple_ssa_name
> {
>     struct tree_base base;
>     tree var;
>     /* `type' is in TREE_TYPE (var) */
>     struct gimple_stmt def_stmt;
>     unsigned int version;
>     struct ssa_use_operand_d imm_uses;
> };


Seems to me that it will all look much nicer when you're done with this! :-)

Gr.
Steven