Re: New insns for the s390 backend (2)

[Bradley Lucier <lucier at math dot purdue dot edu>]

On Wednesday, August 27, 2003, at 09:15  AM, Roger Sayle wrote:

> Hi Brad,
> > I bring this up because some people (like me) would like to have fused
> > madd without setting flag_unsafe_math_optimizations; the latter flag
> > allows so much strange floating-point behavior in the name of
> > performance that it does not meet my needs, and by comparison fmadd
> > is a well-behaved and useful addition to my toolkit.


> Is there any reason to believe that -ffast-math isn't suitable for
> over 95% of GCC's users?

No.

> This I'm happy with, but your previous e-mail
> leads to a slippery slope of some unsafe optimizations being 
> acceptable.

OK, let me explain a bit.

First, I don't think that SPARC has an fmadd instruction; I believe 
early MIPS had one, but more recent processors don't; PPC and s390 have 
them.  I'm sorry, but I'm too tired to look at the config files to see 
if this is correct.

I'm not arguing that fmadd should be the default on s390; I'm arguing 
that there should be a flag separate from 
flag_unsafe_math_optimizations controlling whether fmadd is 
enabled/disabled.  This is the case on rs6000, and I think it should be 
the case on s390.

On rs6000 fmadd is enabled by default.  I have no opinion about this.  
Enabling fmadd is compatible with IEEE 754 arithmetic, since IEEE 754 
does not say what happens you have operations involving more than two 
operands.  Whether one wants to do this or not is another question.  
Sometime (for early Java specifications) you want to disable fmadd.

I have written a fair number of numerical PDE codes and image 
processing codes.  For some things in the library (bit-perfect I/O of 
floats and doubles, etc.), I cannot tolerate 
flag_unsafe-math_optimizations *or* fmadd.  I deal with this by turning 
off flag_unsafe-math_optimizations and writing the code in that part to 
not use fmadd.

In other parts of the code, using FFT for fast bignum arithmetic for 
example, I cannot tolerate flag_unsafe_math_optimizations (since that 
may introduce too large errors in the precomputed sine and cosine 
tables), but fmadd is just fine, since it actually reduces the errors 
when used.  There is a beautiful paper by Colin Percival that gives 
relatively sharp global error bounds for FFTs, and the hypotheses are 
satisfied with our without fmadd, but the hypotheses are not satisfied 
if the sine/cosine tables are not accurate enough.  You need an 
accuracy theorem to do bignum multiplication with FFTs.

So globally I turn off flag_unsafe_math_optimizations, but I allow 
fmadd on PPC and use it whenever it makes sense.  Using fmadd in 
sparse-matrix/vector multiplies also reduces the errors.  So it just 
takes a bit of programming to avoid using it in the places where it 
hurts, and I use it where it helps.

flag_unsafe_math_optimizations is such a coarse tool, and it turns on 
so many questionable transformations and short-cuts in evaluating 
elementary functions, that I can't use it in my codes.  fmadd is a 
specific, well-understood tool that is useful for many codes and in 
many cases reduces the final error.

So I think that fmadd should be controlled by a separate flag.

Brad