This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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?
Gr.
Steven