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: Tue, 25 Nov 2014 10:30:52 +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> <CAFiYyc1=o4_4stw6gL5hLsoWy8xZpJgcJ1UHCGY0Az8s5Wd9JQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1411250047400 dot 11608 at digraph dot polyomino dot org dot uk>
On Tue, Nov 25, 2014 at 2:06 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 24 Nov 2014, Richard Biener wrote:
>
>> > 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.
>
> Even inheriting from tree_base, typically lists don't need code (because
> you know statically that something is a list) or flags. And because
> generally something is statically a list or not a list, there is no
> particular benefit from sharing the static type of tree, and better
> compile-time checking if there is no such common base class for list and
> other objects at all.
>
> (Identifiers are another case that doesn't generally benefit from having a
> common static type of tree.)
All true - but 'tree's were built on the premise that everything is a tree.
An incremental change is to make that sane - removing bits out of
the tree space is also possible (though please not by a wart like
a TYPE_REF tree node ...)
Richard.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com