This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Move FIELD_DECL into it's own structure
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
I suppose you do not want to discourage Dan now by asking the impossible.
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.
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.