[J3] function references and optimization

[Bill Long]

I would say that the vendors cannot make “pedantic standard conforming optimization” the default.  But generally, Tom got it right. Pissing off the people paying the bills is bad business 

Some compilers (at least one I use) support an environment variable that can be defined equal to a text string consisting of compiler options.  The effect is that these options are prepended to the options specified for any compilation, in effect modifying the “default”.  That seems sufficient to satisfy most users.

Cheers,
Bill



> On Oct 9, 2018, at 3:28 PM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> The proverbial cat left that bag long ago …     Users are now accustomed to the “default” behavior of their favorite compiler.  (And rant about defaults in the others that are different.)
> 
> Thus, vendors cannot generally make “standard conforming” the default without significant grief from their users.   It is what it is.
> 
> 
>> On Oct 9, 2018, at 4:21 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> On Tue, 2018-10-09 at 20:15 +0000, Bill Long via J3 wrote:
>>>> On Oct 9, 2018, at 2:44 PM, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
>>>> 
>>>> Van's latest e-mail led me to think
>>>> of a possible problem.  Suppose
>>>> a program contains the statement
>>>> function
>>>> 
>>>>     f(x) = y
>>>> 
>>>> and the assignment statement
>>>> 
>>>>     x = y - f(1.0)
>>>> 
>>>> Does the mathematical equivalence
>>>> rule allow the expression to be
>>>> replaced with 0.0?  What if f is an
>>>> internal procedure that returns the
>>>> value of y?
>>>> 
>>>> Oracle Fortran probably does the
>>>> first optimization at high
>>>> optimization levels.  Statement
>>>> function references are inlined,
>>>> so the optimization phase would
>>>> see the expression as y - y.
>>>> Oracle Fortran probably does
>>>> not do the optimization if f is an
>>>> internal procedure.  The
>>>> optimization could matter if the
>>>> value of y is infinite.
>>> 
>>> Or a NaN.  
>>> 
>>> Like similar examples, I would expect the default behavior to enable
>>> optimizations that improve performance at the expense of strict IEEE
>>> rules. But there are usually compiler options to shut down
>>> optimizations, such as inlining or expression simplification.   If you
>>> have “well behaved” data, the optimized version is usually preferred.
>>> Real world simulations normally don’t involve infinities or NaNs. But
>>> if you want to double check, you can turn off the floating point
>>> optimizations and see if that affects the answer. 
>> 
>> It shouldn't be necessary to turn off things for which the standard
>> makes no provision.  It should be necessary to request them, each one
>> explicitly.  They shouldn't be hiding behind a general level of
>> optimization that does several very useful but perhaps not harmful
>> things.
>> 
>> For example, I'd be happy if the processor does inter-statement register
>> optimization, but not if it secretly does some inter-statement
>> mathematically-equivalent transformations.  The standard's permission
>> for mathematically equivalent transformations applies only within
>> expressions, and only to intrinsic operations.
>> 
>>> Cheers,
>>> Bill
>>> 
>>> 
>>>> 
>>>> Robert Corbett
>>> 
>>> Bill Long                                                                       longb at cray.com
>>> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
>>> Bioinformatics Software Development                      fax:  651-605-9143
>>> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425