Re: Language-independent functions-as-trees representation

[Jason Merrill <jason at redhat dot com>]

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

> On Tue, Jul 23, 2002 at 06:01:21PM +0100, Jason Merrill wrote:
>> On the other hand, going from INITIAL to GENERIC will use a lot of the same
>> functionality as from GENERIC to SIMPLE, so perhaps it would be simpler
>> just to go straight to SIMPLE, using a langhook to handle language-specific
>> trees.

> I think I like this idea.  I can't imagine except that it'd be
> faster, and use less memory in the process.

I would think.

>> > But we need to know whether a tree
>> > node affects flow of control or not.  That's important
>> > for building the flowgraph.
>> 
>> 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 think we also need something to express the absence of ordering
>> restrictions.  If we write f(g(), h()), there will be a sequence point
>> after each of the calls to g and h (at least in C++).  Or if they're
>> inlined, within the calls.  We need to make it explicit that despite the
>> presence of sequence points, the optimizer can switch the two around.
>> That's why I was suggesting something like UNORDERED_LIST.

> Alternately, the number of places in which this applies seems
> relatively limited.  We might be able to do with a langhook 
> that says what order in which arguments may be evaluated.

That could be useful at simplification time, but not after; once we've
simplified, all the arguments are temporary variables or constants, and
their evaluations are serialized.  Likewise for arithmetic operands.

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.

> What other benefits do we get from the complexity of expressing
> the partial ordering of expressions?

I would imagine that there could be some benefit to reordering evaluation
to reduce exception regions for temporary cleanups, or to bring instances
of a common subexpression closer together in the codestream, or whatever.

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

Jason