Re: enforcing expression evaluation order

[mrs at wrs dot com (Mike Stump)]

As you point out, you either have to force fit semantics you want into
those that are availible, put in new rtl codes, or option existing
tree (rtl) codes for those semantics you want.  You didn't mention the
last possibility, but you might consider it.

The advantage of the first, is no change to existing backend and all
the optimizations are already done (in theory).  In terms of code
quality, when optimizing it would be good if the optimizer was
improved if you found any cases where it didn't generate good code.
For the unoptimized case...  :-( I don't know what to say.

The other two possibilities are hard, in that the entire backend along
with all port code has to be examined and `correct'/expanded, a
tedious process.

Now, as to what is best...  Hard to say.  The last two present
problems with people not doing up the optimizing parts to recognize
the new codes, and the one person using them won't spend the time
either, net result, code performance lacks.  The benefit of the first,
is all the beef of the optimizer kicks in, and any non-optimization
found that is fixed, applies to all languages (that use those types of
codes).

Anyway, this stuff should be hidden in the midend, so that one can
replace the low level implementation and representation without
changing a line of your frontend and to offer those semantics to other
languages to reuse them.

I guess I favor SAVE_EXPR to temp everything.  I checked code quality,
and when optimizing my simple case generated the same code, as
expected.  In the non-optimizing case, yes, everything wound up in the
stack (ick).  I think we could have an -O0.5 be the default, and by
default apply some simple well understood optimizations.  This I think
can restore the code in the default case to be the exact same
sequences (quality).