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: Joseph Myers <joseph at codesourcery dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>, Jeff Law <law at redhat dot com>
- Date: Fri, 21 Nov 2014 23:49:03 +0000
- Subject: Re: [RFC] First steps towards segregating types.
- Authentication-results: sourceware.org; auth=none
- References: <546F88E4 dot 1080502 at redhat dot com>
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.
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.
--
Joseph S. Myers
joseph@codesourcery.com