Re: New insns for the s390 backend (2)

[Roger Sayle <roger at eyesopen dot com>]

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.

I wonder if you could explain your needs in a little more detail?
For example, why the inaccuracy introduced by fused-madd is acceptable
in the name of performance but some of the other transformations
performed by flag_unsafe_math_optimizations are not?

I appreciate that this is field specific.  I work in computational
chemistry, writing software to find cures for cancer for the
pharmaceutical industry.  Lots on numerical optimization (energy
minimization as its called here), and strict conformance suites,
such as http://server.ccl.net/cca/data/MMFF94/ that lists the
expected differences resulting from representing a 1/3 formal charge
on an atom using a float vs. double etc...  -ffast-math works for
well for us, reducing CPU times, and often the number of iterations
required by our quasi-newtonian minimizers whilst converging to
the same criteria.

If there are any flag_unsafe_math_optimizations that significantly
produce incorrect results in "real" applications, let me know and
I'll look into disabling them.  However, none of the benchmarks in
SPECcpu2000, including all of the number crunchers in SPECfp2000, fail
their consistency checks with -ffast-math, indeed adding -ffast-math
can often be used to "fix" the failure of 252.eon.  -ffast-math can
often reduce the typical-case error at the expense of worst-case error.

Is there any reason to believe that -ffast-math isn't suitable for
over 95% of GCC's users?  For example, MPEG encoders or audio codecs
etc... Many other commercial compilers apply transformations that GCC
relegates to -ffast-math as too risky by default.


If you care about bit perfect results, why suffer the non-deterministic
and potentially unbounded error introduced by fused-multiply-add insns?
Sorry if I'm a bit defensive, I feel that many of GCC's optimizations
are disabled by default purely to keep a handful of mathematicians, such
as your good self, happy.  For most other programmers, significant
differences caused by -ffast-math reflect poorly written or numerically
unstable applications.  This I'm happy with, but your previous e-mail
leads to a slippery slope of some unsafe optimizations being acceptable.
By default, GCC tries to produce the same results on IEEE-platforms
independent of the presence of fmadd instructions (but fails miserably
on x86!).  You're arguing for non-reproducible results by default on
SPARC, MIPS, PPC and s390, and requiring target specific flags to get
the same answers.

I'm just a bit surprised and confused.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833