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

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

[Ziemowit Laski]

Currently, ObjC does some rather ghastly things with accessors such as 
TYPE_CONTEXT, TREE_PUBLIC and TYPE_MAIN_VARIANT, which are used for its 
own merry purposes in RECORD_TYPEs.  This is a horrible state of 
affairs, and so I'd like to clean up the way ObjC stores its own 
information so that it plays nice(r) with what C and C++ expect.  (This 
work is part of the ongoing ObjC++ integration, BTW, so a prompt 
response would be appreciated.)

There seem to be several ways of attacking this, but I'd like to ask 
the powers that be for the preferred approach before actually 
undertaking it:
(1)  The additional info required for ObjC RECORD_TYPEs is stored as 
attributes, which peacefully co-exist with C/C++ attributes in the
      TYPE_ATTRIBUTES accessor.
(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).
(3)  A variation of (2) in which 'struct lang_type' itself (both in C 
and C++) gets 'struct objc_lang_type *objc_lang_specific' field.

Which of these would be preferable and/or have I left out other 
possibilities?  It seems that (1) would require least (if any!) changes 
to existing GCC infrastructure, but the resulting ObjC/ObjC++ 
compile-time performance would be less than stellar.  Personally, I 
favor (3).

Please advise,

--Zem

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

[Mike Stump]

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).