Re: Language-independent functions-as-trees representation

[Richard Henderson <rth at redhat dot com>]

On Sat, Jul 20, 2002 at 01:47:18PM +0100, Jason Merrill wrote:
> Furthermore, defining expressions to have no side-effects at all would seem
> to exclude CALL_EXPRs, trapping arithmetic, and volatile accesses.  rth,
> what exactly is the distinction you want to express?

In WHIRL, calls are not expressions.  As for trapping arithmetic
and volatile accesses... I have no idea.

I see your point wrt code reuse making it easier to lower the
trees.  I guess I simply wanted stronger typing.  Given that
you're doing a good hunk of the work, I'll defer to what you
think best.

> We still need to address the issue of expressing ordering requirements in
> SIMPLE, as discussed in the third thread above.  For instance, currently
> the tree-ssa branch always simplifies function arguments in left-to-right
> order, which is not required for C and is inefficient on PUSH_ROUNDING
> targets.  We need more tree codes to express these things.  Perhaps
> SEQUENCE_POINT and UNORDERED_LIST would be sufficient.  I guess it's
> reasonable to defer dealing with this until the basic infrastructure is
> done, but I haven't seen an actual decision to that effect, it just seems
> to have been dropped.

No one came up with a good idea.

> In a previous thread, Diego has suggested that inlining would be done on
> language-dependent trees.  I think this is a mistake; IMO it should be done
> at the SIMPLE level.  Requiring the inliner to know about frontend trees is
> wrong.

Indeed.

> The current TARGET_EXPR/WITH_CLEANUP_EXPR/CLEANUP_POINT_EXPR structure is
> unsuited to a structured tree representation; it relies on bookkeeping
> outside of the trees (i.e. expand_decl_cleanup/expand_cleanups).  I think
> we should move some of those into the C++ frontend, as they are useful for
> building up the C++ INITIAL representation, but that when we get to GENERIC 
> they should be replaced with nested TRY_FINALLY_EXPRs.

Yes.



r~