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


On Tue, 2005-05-17 at 01:24 +0200, Steven Bosscher wrote:
> On Tuesday 17 May 2005 01:09, Mark Mitchell wrote:
> > Andrew Pinski wrote:
> > > This is where I am going to say, lets define a type system then because
> > > right
> > > now the middle-end does this which is wrong.
> >
> > I agree, better typing rules would be nice.
> >
> > >> Furthermore, the C++ front end probably shouldn't be doing this kind
> > >> of optimization anyhow; we really want it to be faithful to the source
> > >> representation to the extent reasonable.  (See extensive previous
> > >> discussions on this point.)  It may be that the C++ gimplifier should
> > >> be doing this, but not the front end proper.
> > >
> > > I am going to say the C++ front-end should not using trees
> >
> > 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.
> 
> > The biggest negative -- and one of the reasons that both 
> > Fortran and Ada do not do it that way -- is that using trees does tie
> > you to the rest of GCC.
> 
> ...and the other way around.  Right now, _only_ g++ is in the way of
> some of the major cleanups we could do to the tree data structures,
> because the rest of GCC is tied to G++ via trees.
> 
> 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.

This is very bad, BTW.
It would have been much better to use new tree codes and run out of
space than the current situation.

In reality, we should have struct tree_minimal,  that should probably be
just tree_code, and should be the minimum you need for a tree to be a
tree.

For those trees that have stuff in common, they should share a
structure, but probably not the size of struct tree_common, which
everything shares only because people ignore the flag names and come up
with their own.



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