This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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 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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]