Re: RFC: gimple tuples data structures design

[Diego Novillo <dnovillo at redhat dot com>]

Steven Bosscher wrote on 06/09/06 19:12:

> 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...)?
> 
I was hoping to get away with just type, but I'm not sure if that's
possible yet.

>> /* 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?
> 
Yeah, we discussed this.  We certainly have a lot of padding in
tree_base.  I think a 16 bit code is a good idea.

> Maybe you could move some flags now already?
> 
No particular reason for these flags.  Just to indicate all the padding
we have.  If we make code a 16-bit field, then we don't need all these
flags.  In principle, I'd like to remove all of them.  Initially, we
will probably just move them to tree_common.

> So there is still chain and type here, that's too bad. Ceaning that up
> is outside the scope of your project I suppose.
> 
Initially, yes.  We are not trying to convert everything at once.  The
idea is to move into tree_common fields that we don't want to tackle
right now.  ATM, we are only interested in GIMPLE statements and
assignment expressions.  The goal is to have all of the GIMPLE
statements and expressions "inherit" from tree_base, and allow the front
ends to keep using the traditional tree structures if they want.

> Will these gimple_stmts
> be in containers like struct tree_statement_list_node (which does have
> chain_{next,prev} GTY markers)?
> 
Yes, only in containers.  The GTY maker for next and prev is probably an
oversight.


>> /* Gimple SSA names.
>>
>>    This is the similar to ``tree_ssa_name'' in GENERIC
> 
> Why would we have tree_ssa_name for GENERIC?
> 
We don't.  Aldy was just referring to the current SSA name data structure.