Re: Bug with g77 and -mieee on Alpha Linux

[craig at jcb-sc dot com]

>The point I really wanted to make is that in current, Standard
>Fortran, there is no way to deal with the fact that on some hardware,
>floating point numbers in registers have different precision (and range)
>then when stored in memory.  Therefore, IMHO, the "most" correct way of
>dealing with, say, DOUBLE PRECISION calculations is to store *all*
>intermediate values of computations.  Obviously, this would be very
>costly - so we settle for the less "correct" solution of ignoring all
>issues with intermediate extra precision.  Not having 80-bit spills is
>just one of the ways in which we are ignoring these issues.  We could
>spill floating point registers in 80 (or rather 128) bit chunks, but
>that would still not solve this problem completely.

Yes, well, standard Fortran doesn't imply much of anything useful about
precision and range.

So it is indeed permissible to use 80-bit precision for one computation,
64-bit for another, 32-bit for another, and 3-bit for yet another,
even if all computations are DOUBLE PRECISION in the code!

However, having *computed* an approximation of something (like the
result of evaluating an expression), that *one* approximation is the
only one available from that computation and/or the variable in which
it is stored, by my reading of the standard.

So while not forcing all DOUBLE PRECISION computations to 64 instead of
80 bits, we violate a principle that users accustomed to strict IEEE 754
(or even classic strict FP) machines obeyed, which is "never compute
using more precision that declared".

That's (considered) okay, because the result is much faster performance
on some hardware, and, besides, the Fortran standard does not disallow it.
(Further, it's fairly easy to code around, assuming the *next* principle
is obeyed.)

However, having computed *an* approximation to 80 bits, exposed it in
one code-visible way, then spilled it to 64 bits and afterwards used that
*distinct*, separate approximation in *another* code-visible way, we
violate the vastly more encompassing principle that a given computation
produces exactly *one* (code-visible) result.  (The result may indeed
represent an approximation of a value within some interval -- but, like
quantum mechanics, once *observed*, in the sense of being visible to the
code in any way, that observation is *fixed*, especially by assigning
it to a variable.  That variable cannot, by this principle, subsequently
appear to have *multiple* values.)

Now, this principle I *believe* to be mandated by the Fortran standard.

But, even if it isn't, it is a principle a vastly larger audience accepts
as a "given" than the one that accepts the former principle concerning
never using excess precision at all.

Further, the performance penalty of holding to the latter principle is,
AFAIK, never higher, and sometimes vastly *lower*, on all machines than
the penalty of holding to the former principle.

Now, this is all "water under the bridge", of course.

But it illustrates an aspect of what I have been talking about all along.

The attitudes, among so many who make design decisions affecting the
rest of us, that "nobody should care about low-level precision issues",
"speed is always more important than numeric stability", and so on,
make even mere *verification* that a product is doing the right things
vastly more difficult.  (Further, and this is my greater concern about
the 80-bit-spill issue, these attitudes do *not* defend against what
I believe *will* be future desired optimizations that will make code
*supposedly* resistant to truncated spills start failing.  At which point
those who *like* truncating spills will split into camps -- those who stick
to the "party line" that the *code* must be wrong, and various others who
claim that, to various degrees, the *compiler* is wrong to have made *that*
"extreme" a transformation to the code.)

In particular, those attitudes say, to *both* principles (of expectations
users have regarding FP behavior), "we don't care one whit about you,
we'll break you anytime if it gets us a few more percentage points of
performance on the codes *we* care about".

And now we're paying a very significant penalty for those attitudes.

Which cannot, and *will* (likely) not, be changed merely by changing
any of the particular short-sighted decisions under discussion (not
doing 80-bit spills, not making -mieee the default, to *summarize* --
see my earlier emails for more explanation).

        tq vm, (burley)