On Sat, Jan 22, 2011 at 08:02:33PM +0100, Michael Matz wrote:
> On Sat, 22 Jan 2011, Nathan Froyd wrote:
> > - Similarly to the work I did for s/TREE_CHAIN/DECL_CHAIN/, I'd like to
> > replace TREE_TYPE for things like {POINTER,FUNCTION,ARRAY}_TYPE, etc.
> > This work would be a good step towards both staticizing trees and
> > tuplification of types.
>
> I don't see the advantage in the accessors to that type be named
> differently according to context compared to simply TREE_TYPE.
Well, documentation for one. TREE_TYPE (TREE_TYPE (t)) looks better if
you wrote it as RETURN_TYPE (DECL_TYPE (t)). Maybe it's slightly more
obvious if the variable wasn't named `t' and from the surrounding
context; from the conversion for RETURN_TYPE, though, I don't think it's
obvious. And triply-nested TREE_TYPEs are confusing regardless. :) I
admit that this introduces unnecessary tests to satisfy
--enable-checking builds; I haven't looked whether GCC will optimize out
the extra checks for --disable-checking.
Not all types have a {sub,element}type either. You'd like to be able to
split out those types to make them smaller (tree_type is huge), and
that's hard to do otherwise--you can't use the tree_typed .type member.
(This is the tuplification part.)
If you have statically typed trees, you're also going to have separate
accessors for type of types (see above), type of exprs, type of decls,
etc. even if they share a common base class (tree_base) for lightweight
RTTI. This goal is farther off, even if the proposal is eight years old
at this point.
> If your goal is to make tree_common smaller, introduce a tree_typed
> structure (consisting of tree_base + type member), and use that instead of
> tree_common in all tree structures needing to have a type.
I think that's a good idea, too. But orthogonal to the above.
-Nathan
