We're out of tree codes; now what?

Richard Guenther richard.guenther@gmail.com
Wed Mar 14 09:49:00 GMT 2007


On 3/14/07, Doug Gregor <doug.gregor@gmail.com> wrote:
> Hi Mike,
>
> [I'm replying in this thread to the Objective-C patch you posted in
> the type-traits discussion, because both that post and this one are
> about reducing the number of tree codes]
>
> On 3/13/07, Mike Stump <mrs@apple.com> wrote:
> > I just converted the Objective-C front-end to free up enough tree
> > codes so that Objective-C++ can compile again.  I know it can be
> > done.  If you want a new tree code, you can convert some other tree
> > code into a subcode. pick one one.
>
> Thanks for doing this!
>
> > For ideas, please see the below patch.  I glanced at the C++ front
> > end, I see 8 tree codes (all the tcc_type codes) that you can reclaim
> > using the technique below.
> >
> > For those that want to begin reviewing it, have at it, I'd be
> > interested in, do we even want to go in this direction (we don't have
> > hard numbers on the compile time costs yet, I don't think)?  If so,
> > any better way to do this in the short term?
>
> Emboldened by your patch, I took a quick swing at introducing subcodes
> for the simplest tcc_type node in the C++ front end - TYPEOF_TYPE. The
> patch is attached. Here are some observations:
>
>   - C++ already uses the LANG_TYPE tree code, although certainly not
> the way it was intended: UNKNOWN_TYPE is #define'd to LANG_TYPE. This
> is probably keeping Objective-C++ from working with your patch (I
> didn't try it).
>
>   - C++ already uses TYPE_LANG_SPECIFIC, for class types and for
> pointers to member functions. Those are both based on RECORD_TYPE
> nodes (ugh). That's okay: it turns out that we can use
> TYPE_LANG_SPECIFIC for RECORD_TYPE nodes and LANG_TYPE nodes with no
> problems whatsoever.
>
>   - If C++ uses LANG_TYPE, and Objective C uses LANG_TYPE, we're
> heading for a collision with Objective-C++. Either we'll need use
> different top-level codes (LANG_TYPE vs. OBJC_LANG_TYPE, for example),
> or we need to consolidate LANG_TYPE by making the subtype codes
> extensible by Objective-C++ (just like normal tree codes are). The
> latter seems like the right thing to do.
>
>   - We're also heading toward collisions with lang_type_class, etc.,
> but those are easy to fix.
>
>   - It doesn't seem to happen in the Objective-C front end, but in the
> C++ front end we have a lot of large switches on the TREE_CODE of a
> type. With subcodes, these switches become very clunky. We go from
> something like this:
>
>       switch (TREE_CODE (t))
>       {
>         case TYPEOF_TYPE:
>           /* Handle `typeof' */
>           break;
>
>         default:
>           /* Default case */
>           break;
>       }
>
>    to a two-level solution:
>
>       switch (TREE_CODE (t))
>       {
>         case LANG_TYPE:
>           switch (LANG_TYPE_SUBCODE (t))
>           {
>             case TYPEOF_TYPE_SUBCODE:
>                /* Handle `typeof' */
>                break;
>             default:
>               /* Default case. */
>               break;
>           }
>          break;
>
>         default:
>           /* Default case */
>           break;
>       }

#define LANG_TYPE_CODE (t) (TREE_CODE (t) == LANG_TYPE ?
LANG_TYPE_SUBCODE (t) : INVALID_SUBCODE)

and then INVALID_SUBCODE will fall through to the default case as well.

Richard.



More information about the Gcc mailing list