We're out of tree codes; now what?

Doug Gregor doug.gregor@gmail.com
Wed Mar 21 18:39:00 GMT 2007


On 3/21/07, Mark Mitchell <mark@codesourcery.com> wrote:
> Yes, that's true.  Here, however, we have two paths in front of us:
> 9-bit tree codes, or some language-dependent subcodes.  The benefit of
> 9-bit tree codes is that they're easy to understand; the benefit of
> subcodes is that they might be faster, but, then again, they might use
> more memory.  I'd be interested in understanding the tradeoff.
>
> > Subcodes require a bigger 'tree' data structure so there will be a
> > memory usage hit, I don't think there's disagreement about that.
>
> I thought the plan was to this in TYPE_LANG_SPECIFIC, etc., so that it's
> not a generic effect on all trees?

I think this makes sense. All subcoded types would have their primary
TREE_CODE be LANG_TYPE. The subcode itself would live in
TYPE_LANG_SPECIFIC, along with any additional information we need for
that specific type node.

I suspect we would see a small increase in memory usage, because
subcoded types would have to allocate some memory for
TYPE_LANG_SPECIFIC to point at (it'll be only 4 bytes in most cases).
That said, the tree_type struct desperately needs refactoring, because
there are a lot of fields in there that I suspect aren't used by the
majority of types in the C++ front end, especially those that only
exist in templates (like TYPENAME_TYPE). Something akin to the DECL
hierarchy refactoring is needed.

I'll take a shot at an updated subcode implementation, since I already
have part of it working.

  Cheers,
  Doug



More information about the Gcc mailing list