This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] First steps towards segregating types.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>,Diego Novillo <dnovillo at google dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>,Jeff Law <law at redhat dot com>
- Date: Fri, 21 Nov 2014 21:46:11 +0100
- Subject: Re: [RFC] First steps towards segregating types.
- Authentication-results: sourceware.org; auth=none
- References: <546F88E4 dot 1080502 at redhat dot com> <CAD_=9DRKT-o3egS+r6+Lj3+fuYm6kur-quEOLoaRAurQLB5w8Q at mail dot gmail dot com> <45725310-E6FD-436E-9076-38935D7DD924 at gmail dot com> <546F9EF0 dot 3030107 at redhat 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