This is the mail archive of the
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
On Fri, Aug 23, 2002 at 10:25:14PM -0700, Per Bothner wrote:
> Zack Weinberg wrote:
> >I'm a little concerned about memory consumption if we have to have a
> >COMPOUND_EXPR for (nearly) every statement, on top of whatever sort of
> >thing the statement itself is. A two-operand EXPR node is 24 bytes,
> >which currently gets rounded up to 32 (I plan to fix that).
> Two possible solutions:
> We could have a variable-sized COMPOUND_EXPR (a la TREE_VEC).
> A chain of 20 "statements" is a single COMPOUND_EXPR with 20
> "operands". Compact, fast, great locality, easy to traverse
> in either direction. Not so easy to build of incrementally
> - but for that a parser can use a temporary obstack, or
> temporary TREE_LIST, and then re-cycle the TREE_LIST at the
> end of the block. Or just use 2-operand COMPOUND_EXPR, and
> recycle them at the end of the block.
> This may be awkward for some optimizations, but its more of a
> coding issue than a performance issue, I believe. E.g. an
> optimization that does major re-organization should perhaps
> just copy the entire tree, and throw away the old one. If you
> do only a few insertions, use an extra 2-operand COMPOUND_EXPR.
This is akin to what you were talking about earlier for insn lists.
Personally I like the idea in both contexts -- other nice things are
likely to fall out of it (e.g. it being easy to have tables of
annotations indexed by array offset).
TREE_LIST nodes, incidentally, have ridiculous overhead if being used
as plain old cons chains, or even alists. Four pointers (chain, type,
purpose, value) plus a whole word of flag bits which are generally
I don't have any definite ideas for what *should* be done here -- I
just wanted to raise awareness of the memory overhead involved in the
[Experimentation with different statement tree representations would
be a fine thing to do on the faster-compiler-branch, hint hint...]