This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Move FIELD_DECL into it's own structure
On Mon, 2005-05-23 at 14:09 -0700, Mark Mitchell wrote:
> 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
This is actually what i do.
However, you'll discover that almost every field is used by some tree
I basically instrument the fields i want to move, and then look at all
the places they are shared, and instrument it to make sure it isn't used
both ways by the same _DECL types (if it is, it's usualy a bug, but not
> 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?
I suspect trying to access field names directly should be done as a
followup, if we want to go that way.
> Where is dynamic type-checking still required?
Actually, everywhere, because we still have a union.
Thus, it's possible to access the members even though you really haven't
allocated memory/etc, you'll just screw everything up.
Everywhere you have a common base and
> 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.
> > 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
This is actually a much harder job than one first assumes.
In fact, because of the way we do some stuff at runtime, i'm not
actually sure it's posible
> -- 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.
I have no problem with this.
Although i also have no deviation from the current macro usage planned,
if someone wants to do that, more power to them :)
> 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.