Language-independent functions-as-trees representation

[Jason Merrill]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

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

My point was just that affecting the flow of control is not a difference
between statements and expressions.

>> 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 +?

Sure:

unordered_list
  (
    (a = a + 1, t1 = a + 2),
    (b = b + 1, t2 = b + 3)
  )
t3 = t1 + t2

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

Fair enough.

Jason