Re: Language-independent functions-as-trees representation

[Richard Henderson <rth@redhat.com>]

On Wed, Jul 24, 2002 at 01:14:06AM +0100, Jason Merrill wrote:
> >> Well, anything that can trap affects flow of control; in C++, most
> >> function calls have edges to the local exception handler.  In Java, some
> >> arithmetic does as well.
> 
> > Yes, but I'd say that traping arithmetic cannot be a nested expression.
> > It would only be able to appear as the statement "t = a op b".  Perhaps
> > similarly with trapping memory references.
> 
> In SIMPLE that's as complex as any expression gets.

I guess I don't see your point then.

> It may well be that the optimization opportunities from switching operand
> evaluation around at a later phase of optimization are small compared to
> the complexity of representing it.  But the complexity is also small; an
> initial implementation could just treat UNORDERED_LIST like
> COMPOUND_STMT/EXPR.

That's a highly simplified representation of unsequenced expressions.
Is it enough to represent

	(a++, a + 2) + (b++, b + 3)

which has two ordered pairs, but no ordering across the +?

> Of course, that we don't currently make any attempt to take advantage of
> this opportunity could suggest that indeed it isn't very useful...

It's also a hard problem, so I don't think that's necessarily true.

At the same time, I do think there's probably little to be gained.
Certainly not enough to justify the complexity that I sense is
associated with the problem.  Indeed, I think that most of the
possible benefit would come in the form of relaxed scheduling
constraints, which would mean tracking this partial ordering all
the way through the optimizers.  Which is pretty much a non-starter.


r~