This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix type correctness of fold_indirect_ref
Steven Bosscher wrote:
That's orthogonal. There's no reason you can't write a great front end
But it is hard to write a great back end using trees when at least one
front end has its own set of rules about using trees.
No, that's not true either. It's hard to write a great back end when
you try to interleave the front end and the back end. If the front end
works for a while, stops, and hands some well-defined data structures to
the back end in the format the back end wants, there's no problem.
G++ abuses trees in horrible ways by linking together trees of different
kinds (e.g. TREE_LISTs, *_DECLs, and OVERLOADs) and also by overloading
many tree fields (e.g. TREE_TYPE). This makes cleaning up some fields
in the existing tree structures a tough job.
I agree. Many of these things should not be trees at all, and others
are indeed abused in odd ways. CodeSourcery has been pitching projects
involving improving the G++ data structures at people for years.
Overall, we (not just CodeSourcery, the whole community) have had some
mild succsess in cleaning things up, though there's definitely more to do.
G++ also needs to define a lot of language-specific tree nodes because
it wants a representation that is close to the source code.
I think that's a bit of a stretch. In theory, we could always have just
one tree code for CXX_TREE and then some other discriminator. The truth
is that if we made the things that need not be trees not be trees, there
wouldn't be very many C++-specific tree codes.
There are actually notable advantages of using the same representation
in the front-end and middle-end in that we are able to reuse data
structure -- and even some code -- between the layers. The problem is
that we aren't clear about which layer is which, and what the rules are.