Re: [PATCH]: Move FIELD_DECL into it's own structure

[Mark Mitchell <mark at codesourcery dot com>]

Steven Bosscher wrote:

> I looked into some of this in the past too, but I was not so adventurous
> as Dan to actually try doing the hard work.  The main reason was that it
> is just impossible to determine beforehand how trees are to be split up,
> i.e. it is impossible to do the design of "new tree" up front.  Was this
> not also one of the reasons why Zack&Nathan's static trees idea never
> really took off?

I disagree.  Zack & Nathan's ideas never got implemented because (a) 
they had some new ideas about how exactly this work might best be done, 
and (b) they didn't have time.

In fact, I think it is possible to do much of the design of new tree up 
front, but it does take work.  For example, instrumenting things to 
figure out how things are being (ab)used, and doing some 
experimentation.  I think that there are certainly going to be some 
discoveries made during implementation, but it should be possible to do 
most of the design up front -- and I think it would be beneficial to do so.

It is certainly desirable and possible to do the meta-design up front. 
In particular, assuming that we have determined that there is a 
single-inheritance hierarchy of DECLs, how do we implement that?  Do we 
still want to use macros to access fields, or just expose use field 
names directly?  Where is dynamic type-checking still required?

We could also think a little about questions like: Do we have it as a 
goal that no DECL has a field that is unused, i.e., does that indicate 
that we should automatically have a separate DECL code?    Are we 
willing to accept some empty padding, even if collapsing nodes in the 
hierarchy would reduce total memory usage, at the cost of clarity?  What 
do we do if we get clarity and reduced memory usage, but worse 
compilation times due to other problems with our memory system?  (This 
last is not a rhetorical question; we did prototypes that had exactly 
these problems.)  I don't think these things are as critical as the 
above, though.

> I suppose you do not want to discourage Dan now by asking the impossible.

Certainly not!

> Assuming Dan continues his work, having e.g. GIMPLE_DECL for temporaries 
> (without the many unused fields they have now) would be a Big Win. 

Definitely!

> Wouldn't just documenting a philosophy and posting incremental patches
> be good enough?  Whatever Dan comes up with can't possibly be any worse
> than what 'tree' is now, and isn't the potential for reducing the memory 
> footprint worth the risks you see?

I'm not demanding that Daniel work out the full class hierarchy and 
exactly what is in each class up front.  I think that would be a good 
idea, to tell the truth, and it's what we would do if we were doing the 
project -- but it's so far from the way that people normally operate on 
GCC that it seems unreasonable to ask it.

I certainly think incremental patches is the way to go, independently of 
what parts of the design are done up-front.  In particular, I don't 
think that these changes need to be done on a branch.

So, it may be that you and I are agreeing, depending on what you mean by 
"philosophy".  I'm looking for a document that we can put in the 
internals manual that explains how the tree class hierarchy works so 
that we can understand how things work, and how to add new nodes, and 
new accessors, etc., in a proper way.

Daniel must have a design in mind if he's ready to do the work; all I'm 
asking is that he write it down for our collective benefit.  Either it's 
simple, in which case writing it down should be pretty easy, or it's 
complex, in which case writing it down is very important.

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