This is the mail archive of the gcc@gcc.gnu.org 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: 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
unused.

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
proposed solution.

[Experimentation with different statement tree representations would
be a fine thing to do on the faster-compiler-branch, hint hint...]

zw


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