What optimizations are possible with unsequenced operators?

Question

In C, most binary operators do not specify which operand will be evaluated first:

int x(void) {
    putchar('x');
    return 10;
}
int y(void) {
    putchar('y');
    return 10;
}

// ...

x()+y(); // Unspecified behavior as this may print xy or yx

Many other languages make guarantees that the operands will be evaluated left to right, so the equivalent code in Java is guaranteed to print: xy

Leaving things like these unspecified in C is often done for optimization reasons, so are there any optimizations possible for the compiler to perform when sequence points are not defined between operators such as + = and similar?

Answer 1

Register allocation

This may appear to be a weird answer, but consider these other questions: How many registers are necessary to arrange and call these functions? How many registers to keep alive or spill to memory, to care for intermediate results? What registers are clobbered in general or in this particular case? How much do these questions change on other machines?

These questions need not be answered in general, because C was created to abstract away these machine details and ABI conventions. Yet, C is about generating assembly and binary objects, where these questions are paramount.

Having all this unspecified allows for all sorts of micro optimizations at register allocation level.

And, I suspect, also allows some other tricks at source level, because many compound expressions can be freely (and fully) reordered then is possible, in principle, to examining all combinatorial arrangements of unsequenced subexpressions, to find some combination that uses less or spills less registers in the alternatives.

Divergent incompatible historical implementations

I would also echo the excellent and eloquent points of Eric Lippert and Steve on the comments of the question (and encourage them to elaborate in answers), to point out that the history of C plays a very salient role here.

These details are underspecified on the standard of the language, not to enable unspecified future optimizations, but to accommodate various divergent incompatible historical behaviours in various compilers. Where in one vendor, compiler, or particular machine, one particular optimization is culturally acceptable, desirable and even necessary, in another it was not.

But by the time of language standardization, these incompatibilities were not or could not be worked on, so most of these historical incompatibilities optimizations were left intentionally unspecified.

Answer 2

In many cases, an assignment expression which contains any function calls will need to save one or more temporary values around all but one of the function calls. Putting a function call before any other part of the expression evaluation will avoid the need to store any values related to the evaluation across the call.

For example, given extern int *a,*b,*f(void);, all of the assignments *a=*f()+*b;, *a=*b+f();, and *f() = *a+*b; would be processed most efficiently by performing the function call before the loads of a and b, despite the fact that the function calls appear at different places within the expression.

Performing function calls early is often not considered an "optimization" as such, but may be performed as part of basic code generation if a tree-based expression handler distinguishes between "simple" and "complicated" operands, and processes complicated operands before simple ones.