Should -fcross-jumping be part of -O1?

[Robert Dewar]

Gabriel Dos Reis wrote:

> Robert Dewar <dewar@gnat.com> writes:
> 
> | Scott Robert Ladd wrote:
> | 
> | > And then you have the IEEE-754/IEC-60559 purists who insistent that
> | > using the 80-bit registers is a platform-specific optimization that
> | > destroys reproducibility.
> | 
> | Yes, and they are right but:
> | 
> | a) there is nothing in most language standards that requires
> | reproducibility.
> 
> And that is a language lawyer point of the view that they usually
> think completely useless for their tasks.  At some point, I think they
> are right.

That may sound reasonable, but a requirement of complete reproducibility 
of results for floating-point accuracy would cripple efficiency for the
great majority of programmers who do not care if they get extra 
precision or especially range. It is the range that is hard. Very few
programs *rely* on overflow behavior, and slowing down programs by a
large factor just so that overflow is consistent would seem absurd to
most real life programmers using floating-point.

So this is not at all a language lawyer point of view, but a very 
pragmatic point of view that recognizes that efficiency and purity
are often at odds.

In this case, we are talking about languages which don't define the 
precise results from fpt anyway. In such circumstances, you have to 
regard the results as somewhat non-deterministic.

Ada in fact precisely characterizes the magnitude of allowed
non-deterministic behavior.

Note that in general, we do not expect program behavior to be 
independent of optimization level. If we write a program construct that 
is undefined, or defined to be non-deterministic, then different 
compilers can give different results, different versions of the same
compiler can give different results, and different optimization levels 
can give different results.

Indeed if someone took that attitude that optimization must never affect
floating-point accuracy, I would say that *this* is the language-lawyer
position that ignores pragmatic reality!

We are not talking minor slow downs here, but slow downs by a 
significant factor (which can easily be 2 or 3). Many users of fpt 
cannot even consider this level of inefficiency.