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

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 
> experimentation.  

This is actually what i do.

However, you'll discover that almost every field is used by some tree 
somewhere :)

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. 
> 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 

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.

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