Re: [RFC] First steps towards segregating types.

[Richard Biener <richard dot guenther at gmail dot com>]

On November 21, 2014 9:22:08 PM CET, Andrew MacLeod <amacleod@redhat.com> wrote:
>On 11/21/2014 03:13 PM, Richard Biener wrote:
>> On November 21, 2014 8:45:09 PM CET, Diego Novillo
><dnovillo@google.com> wrote:
>>> On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod
><amacleod@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