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: David Malcolm <dmalcolm at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, 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: Fri, 21 Nov 2014 17:49:54 -0500
- Subject: Re: [RFC] First steps towards segregating types.
- Authentication-results: sourceware.org; auth=none
- References: <546F88E4 dot 1080502 at redhat dot com> <CAD_=9DRKT-o3egS+r6+Lj3+fuYm6kur-quEOLoaRAurQLB5w8Q at mail dot gmail dot com> <45725310-E6FD-436E-9076-38935D7DD924 at gmail dot com>
On Fri, 2014-11-21 at 21:13 +0100, Richard Biener wrote:
> On November 21, 2014 8:45:09 PM CET, Diego Novillo
> <dnovillo@google.com> 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?
> >
> >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.
>
> I don't like either :). It seems you are concerned about uses from
> trees. An intermediate step here that would be useful is doing what
> David did for RTL insns and now gimple - expose tree_type as static
> type but keep tree as its base.
>
> Thus make references to trees that are always types use tree_type *
> while keeping those that can refer to types and sth else refer to
> tree.
>
> That's something that would not be completely artificial at this
> point.
>
> Richard.
>
> >
> >Diego.
I had a look at doing this a while back, but I ran into an issue: the
base type, "union tree_node", is a union, rather than a struct, and you
can't subclass a union.
But perhaps something like this might work:
union tree_node {
/* the huge list of fields */
};
/* put it into a struct, so we can subclass it: */
struct tree_base_class {
union tree_node m_massive_union;
};
/* now subclass it: */
struct tree_type : public tree_base_class {
/* empty, but expresses the invariant that it's a type,
like rtx_insn vs rtx_def. */
};
and then use tree_type * everywhere where it's appropriate, capturing
the type vs expression separation.
Not sure what that would do to the memory requirements of the compiler,
but might give you a smoother path to doing this.
Hope this is constructive
Dave