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: Joseph Myers <joseph at codesourcery dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Mon, 24 Nov 2014 12:50:38 +0100
- Subject: Re: [RFC] First steps towards segregating types.
- Authentication-results: sourceware.org; auth=none
- References: <546F88E4 dot 1080502 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1411212338170 dot 32250 at digraph dot polyomino dot org dot uk>
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