Re: [RFC] First steps towards segregating types.

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

On Sat, Nov 22, 2014 at 12:49 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 21 Nov 2014, Andrew MacLeod wrote:
>
>> The biggest issue is what to do with fields which can be either a type or a
>> tree...  ie   TREE_VALUE() of a TREE_LIST can be a type, as can  a TREE_VEC
>> element or a DECL_CONTEXT.  I think the DECL_INITIAL field is overloaded and
>> can sometimes be a type, and this was recently introduced to
>> TARGET_STATIC_CHAIN.  I suspect the compilation process will identify others.
>>
>> Looking primarily at TREE_LIST first (which can  be a mixed list of trees and
>> types),  the question is how to generally handle this situation
>
> TREE_LIST should die (with the typical replacement being vec<something>);
> most lists do not need all the overhead of individually allocated objects
> with (code, flags, type, chain, value, purpose).  Probably TREE_VEC too.

Note that there is nothing wrong with TREE_LIST or TREE_VEC if
they were based off tree_base only.  That they inherit from
tree_common is the bug to fix - either by not using TREE_LIST or
TREE_VEC from the users that use fields from tree_common or
tree_typed or by adjusting those users to not need those fields.

> That doesn't answer your question - making lists and vectors no longer
> have the static type "tree" ought to be essentially independent cleanups
> from making types no longer have the static type "tree", rather than being
> dependencies of that.  But it's a goal to keep in mind when there's a
> choice of what to do about a particular TREE_LIST or TREE_VEC case.

Correct.

I still think that statically typing 'tree' fields that are always
tree_type_common to sth like 'ttype' (following 'gassign' naming
convention) is something to explore.  Whether it needs turing
'tree' upside-down (get rid of the union) I am not sure.

Richard.

> --
> Joseph S. Myers
> joseph@codesourcery.com