Re: Draft "Unsafe fp optimizations" project description.

["Tim Prince" <tprince at computer dot org>]

----- Original Message -----
From: "Toon Moene" <toon@moene.indiv.nluug.nl>
To: <dewar@gnat.com>
Cc: <gcc@gcc.gnu.org>; <lucier@math.purdue.edu>
Sent: Saturday, August 04, 2001 8:19 AM
Subject: Re: Draft "Unsafe fp optimizations" project description.


> dewar@gnat.com wrote:
>
> > Some comments
>
> Thanks !
>
I want to thank Toon for undertaking this.  It looks like a good start
toward filling in a deficiency which many compilers share.  Most
compilers leave it up to the individual to find out what they do in this
area, how to control it, and spring surprises with new releases.

One of my original reasons for provoking this discussion was my hope of
dealing with the need to conform with C and Fortran standards, which
require re-association to be preventable by parentheses, even though
optimizations such as -ffast-math are in effect.  According to my
understanding, it is not feasible to guarantee that gcc will do this,
and thus I believed it important to have additional sub-options
under -ffast-math which would turn off individual types of alterations,
such as those which re-arrange division in a way which could produce
overflow.

I think that, strictly speaking, A/B -> A*(1/B) should not occur by
default under -ffast-math, as writing (A/B) could never suffice to
prevent it.  Such a position, though justifiable, would be contrary to
long standing practice and would make it quite difficult to obtain good
performance with code which was not written with optimization in mind.
So, I don't have a position on it other than to wish for a documented
provision to control whether it happens, without disabling all
other -ffast-math treatments.

> The problem is: What constitutes a surprise ?  If I ask for "force
> denormals to zero" I know that I might run into a divide-by-zero
error,
> so I do not think of that as a surprise.  To make it "not-a-surprise"
to
> anyone, it should be documented.
>
Instituting abrupt underflow also avoids, on an an otherwise
IEEE-compliant system, the possibility of unexpected overflow in the
replacement A/B -> A*(1/B) . Old-fashioned code which checks for a zero
value before dividing comes back to working order.  Not to mention the
totally unexpected abysmal performance when moving to a system which
lacks hardware support for de-normalized storage.