Print

Print


Walt Brainerd <[log in to unmask]>wrote:
...
>I agree that the standard doesn't have the same words about
>multi-statement
>optimization, but we all know it "must be allowed".  Otherwise, a
>compiler
>would not be free to move a statement out from the following loop (no
>aliasing
>among x, t, y and a, of course):
>
>do i = 1, n
>   x = cos (6.5*t) + y
>   a(i) = a(i) + x
>end do

Well, the "as-if" rule clearly applies.  I doesn't matter to the meaning 
of the above whether X is computed once before the loop executes
or whether you compute the expression every time.  So, the result
is indistinguishable (except for speed).  It is generally held that, in
such cases, the optimization is valid regardless of the apparent
constraints of the language standard.

Now, suppose it were the case that moving the evaluation of X 
outside the loop removed it from the numeric processor's stack, 
and that change reduces the precision to which X is stored.  You 
could make the argument that such an optimization was invalid 
(the change would certainly no longer be covered by the "as-if" rule).  
Your complaint (in this case) would probably not be upheld since 
the standard doesn't guarantee any particular precision(!?).

These are muddy waters.  The purpose of parenthesis is to force 
evaluation order so that the user can insure numerical stability.  The 
same could be said of Kurt Hirchert's example:

  T = B + C
  D = A * T

In spite of that purpose though, the standard doesn't make any
constraints on numerical accuracy.  Vendors can (and sometimes
do) defend optimizations (such as the loop invariant removal)
as being valid: since you have no right to expect better precision
than can be stored in the type of X anyway.  But where's the dividing
line?  Somewhere between the level of parenthesis (which *do* 
force order) and the level of accepted optimizations (such as
moving loop invariants) there is a gray area.  I'm not even sure
which side of the line Kurt Hirchert's example falls on.  (In fact,
I suspect that using the distributive law would be disallowed.
I suspect that loss of precision - or extra precision - because of
whether T were actually stored or not *would* be allowed.)

This is not merely an academic exercise.  I've heard that the work
on interval arithmetic was held up on this very issue for some time.
This is probably one of the reasons that interval arithmetic was
dropped from the present cycle.  It would probably be good
to have this issue directly addressed (but who has the time?).

--
J. Giles



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%