Re: [RFC] First steps towards segregating types.

[Andrew MacLeod <amacleod at redhat dot com>]

On 11/21/2014 02:45 PM, Diego Novillo 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?
The opposite I think...  option 2 requires compile time correctness.   
In order to get option 1 it right, anywhere there is a TYPE_REF we're 
going to have to change it to look through the TYPE_REF to get the 
type.  If we don't then I'll probably end up with run-time errors in the 
main branch when TREE_VALUE() gets an unexpected TYPE_REF, or something 
like that.  Im also somewhat concerned about places which use it as an 
LVALUE and write the wrong sort of thing back in.  Won't catch that 
until runtime either.   I'll know more next week about that aspect with 
some practical implementation.

Maybe even a combination... change to the get,set,ptr model for 
accessors, AND then use TYPE_REF....    although at the same time i'd be 
nice to ditch the TREE_VALUE_PTR variations... thats virtually the same 
thing as an LVALUE :-P.   that is non-trivial however.  perhaps thats a 
bad idea :-)

> 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.
Its also relatively easy to change individual cases from option 2 to 
option 1 down the road.   vice versa is not true :-)

Andrew