On November 21, 2014 9:22:08 PM CET, Andrew MacLeod <amacl...@redhat.com> wrote: >On 11/21/2014 03:13 PM, Richard Biener wrote: >> On November 21, 2014 8:45:09 PM CET, Diego Novillo ><dnovi...@google.com> wrote: >>> On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod ><amacl...@redhat.com> >>> wrote: >>> >>>> 1 - introduce a TYPE_REF tree node, which is effectively just a >>> 'typed' tree >>>> node, and the TREE_TYPE() field of a TYPE_REF node would point to >the >>> type >>>> node. Any routines which utilize a TYPE node in a tree list would >>> have to >>>> be modified to make use of this new TYPE_REF node to refer to the >>> type. >>>> 2 - change the field (list->value in this case) to be a tagged >union >>> of { >>>> tree tree_value, tree_type_ptr type_value } and use a bit in the >base >>> to >>>> flag which kind of value it is. This would be compatible with GTY, >>> and would >>>> require changing routines and algorithms to check the bit and use >the >>> right >>>> field. >>> Seems to me that option 2 would also help against code that blindly >>> looks at TREE_VALUE and assumes it to be a tree. Wouldn't that make >>> initial implementation a bit more challenging? >>> >>> Option 1 does seem easier, but I kind of like the forcing of rvalues >>> that option 2 provides. >>> >>> Also liking option 1. The final change to the final type should be >>> simpler that way. >> I don't like either :). It seems you are concerned about uses from >trees. An intermediate step here that would be useful is doing what >David did for RTL insns and now gimple - expose tree_type as static >type but keep tree as its base. > >Didn't say I was thrilled with either, just the only 2 I had come up >with :-) >> Thus make references to trees that are always types use tree_type * >while keeping those that can refer to types and sth else refer to tree. >> >> That's something that would not be completely artificial at this >point. >> >> Richard. >> >> > > >Or possibly a third type which is a hybrid of the two, and also maps to > >a tree... something like tree_type_hybrid * > >That could work, and will continue to highlight all the places which >still need to be dealt with.
Well, on a case by case basis you could find a better union in the tree type hierarchy. Richard. >And it's much less work.. :-) I'll give that a go and see how it plays >out. > >Thanks >Andrew