[RFC] type safe trees

[Geoff Keating]

On 24/06/2004, at 1:54 AM, Nathan Sidwell wrote:

> The comments on the type safe tree proposal have split into some small
> technical issues, and the language one.
>
> The language one is why don't we do this in C++ and be done? If
> we were starting from a clean slate, that'd be a nobrainer. We're not.
> Anyway, there seems to be buy in from several global write maintainers
> for doing this, so we need an SC descision.  I'm about to send that.

Could you list the maintainers that thought this was a good idea?

You might be thinking that I thought this was a good idea, for 
instance, and at present I am not convinced.

> The technical points were,
...
> > - Removing one field at a time doesn't have much effect on these
> >   50-field structures.
> That was an example of why we definitely need more than two levels
> of heirarchy.  Please don't take that as a cast in stone design.  the 
> big
> breakpoints with decls that I see are
> 	const_decls (we have *huge* const_decls right now)
> 	var_decls
> 	function_decls

We actually did an experiment with shrinking CONST_DECLs.  It wasn't 
very impressive; there aren't enough of them to make a difference, and 
they mostly live in PCH files and never get used, which is cheap.

> > - The real problem is the underlying design of the structures, not 
> the
> >   number of pointers in each structure.
> yes, I'm sure many can be made more efficient, in a similar way to what
> you say about FUNCTION_DECL

... but you understand that just trying to keep the existing structure 
and removing unused fields won't help very much?

> > - I think the TREE_LIST-ectomy should happen before we try these more
> >   complicated approaches.
> Entirely agree. (No one's commented on my vector patch :)
> When I looked for an example TREE_LIST to change, I picked
> CLASSTYPE_VBASECLASSES because that vbases field was not multipurposed
> (read our paper for explanation of terms), thus I could change its type
> easily.  To complete the list-ectomy would require either
> 1) adding more union members and associated GTY gunk
> 2) removing all multipurposing, as Zack outlined in the talk.
>
> It would be wise to know where we're going, before we proceed very far
> down either route.

I think you'll want a combination of both.

> > Don't get seduced by the 'big problem requires big change' mentality!
> > At Apple, we've found that there is no correlation between the size
> > of the change and the performance benefit it gives, except that it 
> seems
> > that very large changes are more likely to produce no benefit at all
> > because either they can't be made to work or they were aimed at the 
> wrong
> > problem.
> thanks for this insight.  Indeed, I thought 'use C++' was too big a 
> change!
> We definitely want a change that can be done incrementally.

Right, but each change must be fully justified.  For instance, don't 
say "this patch converts GCC to use C++ and gives a 1% performance 
benefit, but there'll be more later".  Very often, 'later' never comes; 
that 1% is all you ever get; or worse, you get 10% later but you could 
have gotten it without the first change, and now you're committed.