This is the mail archive of the
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
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.
Alternatively, we can just use the TREE_CHAIN of expression
nodes to chain them Some valid expressions, including
constants and declaration references would need to be wrapped
in some other expression, if they are to be chained, but
that is any enough.
The solution of just chaining expressions together does the
smentic problem of when are we talking about the component
expression, and are we talking about the chain. Should expand_expr
applied to an expression implicitly also expand its TREE_CHAIN?
That appears to be what c-semantics.c does, at first glance.