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 Monday 23 May 2005 21:15, Mark Mitchell wrote:
> > Even if i split three _DECL trees and leave the rest in
> > tree_decl_non_common, how are we *worse* off?
> Because we might not know how to move forward, or what the overarching
> design had been.  At present, we at least understand what we've got --
> one giant overloaded union.

...which is probably a problem for...

> what
> I'm asking is that you contribute a design before doing any of the work,
> so that we have that, both for documentation and so that other people
> can help you.

...this.  Everything is so tangled right now :-(

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 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.  That
is something we should all want (especially given the lengthy threads
about memory footprint problems recently ;-)

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?


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