(j3.2006) F03/0084, was Re: Interp letter ballot #25

[Van Snyder]

On Mon, 2012-05-14 at 12:07 -0600, Keith Bierman wrote:
> But we digress. As Malcom aptly notes, the interp at hand really
> shouldn't drag intervals back into the spotlight. 

Right.  It really has to do with the range of applicability of
"mathematical equivalence" between different statements, for purposes of
optimization.

If we want to get this right, and avoid further controversy and
confusion, we should specify that mathematical equivalence does not
apply to expressions that might be evaluated with different rounding
modes in effect, that involve operands whose values might have changed
(including but not limited to those that have the VOLATILE attribute),
or that are evaluated in different segments.

This could be specified in the answer to the interpretation -- without
any edits, and therefore no new features, and no new
"optimisation-disabling" effects.

On Mon, 2012-05-14 at 12:16 +0900, Malcolm Cohen wrote:

> >If "mathematically equivalent" includes "ignore IEEE rounding mode
> >changes"
> 
> No it does not.
> 
> > then we might as well remove the rounding mode facilities from
> >the IEEE modules, since the result of this interpretation is "they don't
> >actually work anyway."
> 
> They do work, they apply to the actual operations being executed.

> The rounding mode applies to the actual operations being 
> executed.  The point being that after the permitted mathematical 
> transformations, there are no operations being executed.

The point of my comment, which was apparently not well understood, was
that the interpretation incorrectly argues to allow the transformation,
resulting in no operations being executed, thereby effectively
subverting the program's obvious desire to carry out the calculations,
and to do so with different rounding modes.

Setting a rounding mode means that evaluating <expr> is really the
mathematical operation <expr> + f(<expr>), where "f" is different for
each rounding mode.  Arguing that since f(<expr>) doesn't appear in the
text, it doesn't exist, and therefore doesn't count for purposes of
"mathematidal equivalence," is arguing that rounding mode setting
changes can be ignored in conformant programs.

> Note that the rounding mode is inherited, so IEEE_SET_ROUNDING_MODE is 
> frequently not visible.

It's either visible, or invoked in an impure procedure.  Is it allowed
to exploit "mathematical equivalence" for optimizations spanning
invocations of impure procedures?

> That means that any optimisation-disabling effect that you apparently
> want it to have would potentially need to be applied to the 
> entire program.

Grotesquely exaggerated nonsense.  It's not the rounding mode that
causes problems for optimization, it's the rounding mode _CHANGE_!
Unless a program consists of 50% rounding-mode changes, there are no
significant "optimisation-disabling" effects.

Do we contemplate allowing simplifications based upon mathematical
equivalence spanning coarray synchronization points?  I think not.  How
is prohibiting it from spanning changes of rounding modes any different,
or any more of an "optimisation-disabling" effect?

> My comment was simply showing one way of disabling unwanted optimisations, a way 
> that works fairly locally....  A single assignment 
> to and reading from a VOLATILE variable is often cheaper than a whole external 
> procedure invocation (the more traditional way of road-blocking the optimiser).

There's nothing in 5.3.19 that prohibits exploiting mathematical
equivalence to subvert the effect most readers expect of VOLATILE.
Applying the VOLATILE attribute is not, therefore, a way of "blocking
unwanted optimisations."  Assuming X, Y, Z1, and Z2 have the VOLATILE
attribute, if one writes

Z1 = X * Y
Z2 = X * Y
print *, Z1 - Z2

a conformant processor is free to exploit mathematical equivalence to
eliminate the  assignments and the subtraction, and always print zero.

I can already hear the chorus of "But, but, but... 5.3.19p1 says that an
object with the VOLATILE attribute "may be redefined, defined, or become
undefined, by means not specified by the program."  That's a
_computational_ difference, not a _mathematical_ difference.