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.
And it's much less work.. :-) I'll give that a go and see how it plays out.
Thanks
Andrew
