Re: Question: Need to store ObjC-specific info in type nodes.

[Mike Stump <mrs at apple dot com>]

On Thursday, September 23, 2004, at 03:41  PM, Ziemowit Laski wrote:
> (2)  In addition to a 'struct lang_type *lang_specific' field, each 
> type node also gets a 'struct objc_lang_type *objc_lang_specific' 
> field (set to NULL in plain C and C++ modes).

An object factory for these so that a language can have special rules 
to decide on the exact run time type of the tree may be useful.  That 
immediately gets rid of 4 bytes for every type and decl and speeds up 
all accesses to all data not in the common bases (tree_type and 
tree_decl), which I think is a good direction to move in.

These can be done through the lang hooks.  MAKE_TYPE is an existing 
look that kinda does what I am thinking, at least in part.  
Specifically, instead of calling make_node as cp/lex.c:cxx_make_type 
does, it would allocate the size, and then call make_node (code, size), 
and then the fields can be directly accessed.  The runtime 
discriminators (such as is_lang_type_class, see also 
tree_node_structure) would still be necessary.  Some of the runtime 
discriminators would be able to go away (u1sel, u2sel, u3sel and 
can_be_full. Se also CAN_HAVE_FULL_LANG_DECL_P) I suspect.

Or, one can just change tree_code_size to virtualize getting the size 
information for decls and types.  I don't expect that would cover all 
the existing uses (is_lang_type_class for example), but it might be 
able to pick up most uses).