We're out of tree codes; now what?

[Mike Stump]

On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote:
> When I said, let's support Doug, I meant let's support Doug from a  
> *practical* point of view. Either we suggest something doable with  
> a realistically sized effort or a little larger and at the same  
> time we volunteer to actually do it. In my opinion, "visions" for a  
> better future do not help here.

I'd disagree.  It is nice to have a stated idea of where we want to  
go, even if we can't get there today.  We can measures patch goodness  
by how closely each patch moves us in that direction.  That said, we  
all realize we are _not_ asking Doug to please re-implement the C++  
frontend to our design to fix this issue.  I'd be against that.   
Making C++ use a few tree codes (a la the back end) and burying the  
`extended' code in the C++ frontend sounds enticing, sounds like less  
work than redoing the FE to not use trees entirely and a step in the  
right direction.  I checked the Objective-C frontend, it seems  
possible to do it as well.  The tree_contains_struct stuff seems the  
`hardest' to get right, though, for Objective-C I think we could get  
by with 2 tree codes, maybe.  Those that have TS_DECL_NON_COMMON,  
TS_DECL_WITH_VIS, TS_DECL_WRTL, TS_DECL_MINIMAL and TS_DECL_COMMON  
and those without?

I looked at all uses of the Objective-C specific tree codes, and they  
all seemed to come in two forms:

TREE_CODE (t) == <OBJ_TREE_CODE>
and build_routine (<OBJ_TREE_CODE>, ...)

The first can be replaced with

   OBJ_TREE_CODE_P (t) and it could do (TREE_CODE (t) ==  
OBJ_COMMON_CODE && OBJC_TREE_CODE (t) == <OBJ_TREE_CODE>) or some such.

The second can be almost left as is, and ultimately the builder can  
build with OBJ_COMMON_CODE and then stuff code into OBJC_TREE_CODE.

I'm hoping that might allow us to reduce the pressure enough so that  
we can fit back down into 8 bits, so as to avoid the memory size  
increase and (the unmeasured) slowdowns that would result.  Objective- 
C/C++ would slow down, but, faced with the slowdown that would be  
certain if we didn't do this, I don't see how we could not.  The  
benefit, all other languages would not, which is still important to us.

The good news, in Objective-C 2.0, we only need 1 more tree code.

If we did do this, we'd have to put in a mandate, no more new tree  
codes (unless you rewrite the Objective or C++ FE to stop using a code).

Thoughts?  Is it rally worth trying to do this?  What happens when we  
need 1 more unique (wrt tree_contains_struct) code for Objective-C?