This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] First steps towards segregating types.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]