This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
Jason Merrill wrote:
This does sound awkward, particularly for simplification. In the code I've
been writing which uses 2-operand COMPOUND_EXPR, simplifying a complex
statement just means replacing it with a COMPOUND_EXPR; later, we go
through and flatten the COMPOUND_EXPRs so that they're only
right-recursive. Of course, this last step could replace them with a
variable-sized one instead, but this would add complexity in order to avoid
doing it too early.
If you do have a flatten pass, I don't see how that is any worse
than just copying into a multi=opeand COMPOUND_EXPR.
Allocating and then throwing away all these COMPOUND_EXPRs would use even
more memory in the short term than just using the 2-operand forms, since we
don't do GC until we're done with the function. We might be able to reduce
the wastage by using a varray for temporary storage.
Or possibly the temporary_obstack.
Of course, even an array involves more memory use and pointer chasing than
just using the TREE_CHAIN.
If we ever get around to cleaning up our tree representation, in favor
of something more strongly typed, then I'd like to get rid of
TREE_CHAIN. It's wasted in many nodes. When it's not wasted, it blurs
(as I mention later) the semantic distinction betwen a node and a set of
nodes. The main use for TREE_CHAIN is for chains of declarations in a
scope; these should be handled by a TREE_VEC-like DECL_GROUP node.
I'm not compelled by any of the options mentioned. Any other opinions?
We could re-consider the IF_STMT vs COND_EXPR. What is the difference?
As I understand it:
* A COND_EXPR may have a non-void type. Compounds are created
using COMPOUND_EXPR.
* An IF_EXPR uses the TREE_CHAIN to create compounds.
Otherwise, they're both 3-operand expression nodes.
Using a a COND_EXPR's TREE_CHAIN would be more-or-less the same as
how the existing IF_STMT is used. So perhaps we could just use
the current IF_STMT implementation, add support for non-void,
and re-name it COND_EXPR ...
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/