This is the mail archive of the
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
- From: Richard Henderson <rth at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Per Bothner <per at bothner dot com>, Diego Novillo <dnovillo at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Sat, 20 Jul 2002 13:50:28 -0700
- Subject: Re: Language-independent functions-as-trees representation
- References: <firstname.lastname@example.org>
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
> 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
> 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.