> I don't see anything about Tree that I find inherently awful; in fact, > it looks very much like what I see in other front ends. There are > aspects I dislike (overuse of pointers, lack of type-safety, unncessary > copies of types), but I couldn't possibly justify changing the C++ > front-end, for example, to use something entirely other than Tree. That > would be a big project, and I don't see much benefit; I think that the > things I don't like can be fixed incrementally. > > (For example, it occurred to me a while back that by fixing the internal > type-correctness of expressions, which we want to do anyhow, we could > eliminate TREE_TYPE from expression nodes, which would save a pointer.)
Steven has a point here is that currently the trees are way over-bloated because they contain both front-end and middle-end info. This has been a problem since trees have been in GCC (which is the begining). I should note that some expression nodes still will need TREE_TYPE. Though TREE_TYPE is only part of the issue. TREE_CHAIN is the worst offender here in general as it is used by the front-end to do things which make less sense than what it is there for. Steven can comment more on this since he tried to remove TREE_CHAIN before but the C++ front-end was (ab)using it more than he could fix. There are other bits which are ovbiously front-end only bits, the following for examples in tree_common: unsigned private_flag : 1; /* not in CALL_EXPR or RESULT_DECL/PARM_DECL */ unsigned protected_flag : 1; /* not in CALL_EXPR */ unsigned deprecated_flag : 1; /* not in IDENTIFIER_NODE, just added too */ unsigned lang_flag_0 : 1; unsigned lang_flag_1 : 1; unsigned lang_flag_2 : 1; unsigned lang_flag_3 : 1; unsigned lang_flag_4 : 1; unsigned lang_flag_5 : 1; unsigned lang_flag_6 : 1; in expressions: int complexity; in types: unsigned lang_flag_0 : 1; unsigned lang_flag_1 : 1; unsigned lang_flag_2 : 1; unsigned lang_flag_3 : 1; unsigned lang_flag_4 : 1; unsigned lang_flag_5 : 1; unsigned lang_flag_6 : 1; unsigned needs_constructing_flag : 1; binfo in general (why is this even in tree.h?) And many more examples latter on in tree.h. -- Pinski
