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

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,

It's possible, it's just an incredibly large amount of work

I plan on documenting *how* i split them up, how to add new trees, how to deal with inheritance and checking, and when they should be split up.

I'm writing this stuff on the wiki right now.

I can't possibly document what the complete, new hierarchy will end up looking like because it depends on what people decide the solutions to various "what are currently trees, but maybe shouldn't be" problems are.

I can document what my current thoughts are about what will happen, but again in terms of hierarchy, they may turn out to be wrong or not split up enough.

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?

Dunno. The static trees involved more casting, IIRC.

My whole evil plan is to have a single inheritance hierarchy for _DECL, and if this means occasionally we have to waste 4 bytes because of it, *that's* not so big a problem, as long as we are wasting 4 bytes out of 64, not 4 bytes out of 208 :)

Thus, as it stands, i plan on simply increasing the number of tree node structures. At worst, we have O(number of tree codes) + <a small number> of tree structures in our hierarchy.

I should also note my current plans only include _DECL nodes, but the same principles could be applied to *all* our tree nodes.

If our worst problem was that tree_common was taking up half the DECL node, at bytes, well, we'll deal with it then. :)

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]