Re: [PATCH] Fix type correctness of fold_indirect_ref

[Mark Mitchell <mark at codesourcery dot com>]

Steven Bosscher wrote:
> On Tuesday 17 May 2005 02:15, Mark Mitchell wrote:
>
> > 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.
>
>
> You forget that we drag around all the language specific extensions to
> trees as well.  Things lang_identifier, lang_decl, and lang_type are a
> major pain.  Do you have any idea how large a simple scalar temporary
> is in the tree optimizers for G++?  Our struct tree_decl is already not
> exactly a fine example of lean and mean, but lang_decl and (especially)
> lang_identifier make it a real pain.  (I'm aware that making DECL_*NAME
> strings would fix this, it's a major project we should list somewhere).

Yes, I am aware of the data structure bloat.  In fact, we've probably 
researched this in at least as much detail as anybody else.

However, that's again simply bad datastructure design; it's not 
something intrinsically wrong about sharing a representation with the 
back end.  With proper data structures, using inheritance idioms, 
there's no reason that we can't have things like VAR_DECL (with just the 
minimal information necessary for middle-end generated temporaries) and 
CXX_VAR_DECL (with all the extra C++ information).

> But you would still have pointers from trees to non-trees, and the other
> way around. 

Yes.  But, nothing in the middle-end would have to know about these 
pointers, or care about them.

> E.g. do you think OVERLOAD should be a tree?

Yes, I do.  In general, I think things should be a tree if they appear 
as a component of an expression, statement, or declaration.  So, 
OVERLOADs are trees, but TINST_LEVEL certainly should not be.  (Well, to 
refine, I think we should have expression and declaration, both of which 
inherit from tree, but that's a technicality.)

But, OVERLOAD should not have a TREE_TYPE, or TREE_STATIC, etc.  And, 
even if the C++ front end did not use trees, it would still be sensible 
to make it possible for trees not to have these fields; certainly, the 
optimizers don't need TREE_STATIC on everything they manipulate.

There are also places where the middle end makes unnecessary 
distinctions.  It would be perfectly reasonable to collapse POINTER_TYPE 
and REFERENCE_TYPE, perhaps with an extra bit to say if something is a 
reference, if that idea has meaning to the middle end.  If it doesn't 
have meaning to the middle end, then we should could use a 
language-specific bit to distinguish these concepts in front ends.

I can guarantee you that if we did a sensible redesign of the data 
structures, but found that in so doing we needed an extra couple of bits 
to allow us to have, say, 512 tree codes, that we would still have a 
massive win in terms of memory.  Tree codes aren't taking up the space.

Anyhow, I can say this with certainty: rewriting the C++ front end to 
make it not use trees is a major undertaking.  It has dubious benefits. 
 I wouldn't plan on that happenning.  Fixing abuses of trees and 
redesigning data structures is much more likely to happen.

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