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?
