This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
using trees.


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.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]