This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should -fcross-jumping be part of -O1?


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]