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

Bill Long longb
Mon May 14 18:33:55 EDT 2012

On 5/14/12 5:20 PM, Van Snyder wrote:
> 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.

And yet your list of suggestions already includes some 
optimization-disabling effects.  Why even venture into this mine field? 
   The outcome would almost certainly be even more interps.


> 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.
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

More information about the J3 mailing list