[comp.arch] optimization and IEEE arithmetic

johnl@iecc.cambridge.ma.us (John R. Levine) (06/21/91)

In article <9106190124.AA27410@ucbvax.Berkeley.EDU> J. Shearer writes:
>      IF ( ( B .GT. 3.0 ) .OR. MYTEST(A) )
>[MYTEST prints a message which doesn't appear if the .OR. is short-
>circuited]

I believe that the point is that short-circuit evaluation of a logical
expression, or of any expression for that matter, is a perfectly legitimate
thing for a Fortran translator to do.  The F77 standard specifically says so,
and in fact the test program is not correct Fortran because it depends on the
side-effect of a function.  You can look it up.

Evidently none of the IBM compilers short-circuit a logical expression, which
is surprising because it is a potentially large source of speedup.  The
Fortran standard is deliberately ambiguous in places exactly because its
authors wanted to allow implementors as much latitude as possible to produce
fast object code.  That means that there are many cases where there is more
than one legal way to translate a construct.  If two compilers make different
choices, or if one compiler makes different choices depending on optimization
switches, that doesn't mean the compiler is broken.  It does mean that any
program that works with one choice and not another is not good Fortran.

Here's an example from the F77 standard that will strike horror into the
hearts of IEEE devotees (of whom I am one):

If you write

	X = A*B + A*C

the standard specifically says that it's legitimate to compile it as:

	X = A * (B+C)

The converse translation isn't permitted because it has to obey parentheses.
If you really want the first, you'd better write this:

	X = (A*B) + (A*C)

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl