Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[Linus Torvalds <torvalds@transmeta.com>]

In article < 004501c117f4$84a48c80$9865fea9@timayum4srqln4 > you write:
>
>This optimization is specifically permitted for appropriate data types
>by the Fortran standard, with the reservation that parentheses employed
>to prevent re-association must be observed.  As gcc is unable to
>distinguish between the expressions (a/b)/c and a/b/c, this optimization
>would violate the standard in the former case, so is undesirable for
>enabling under -ffast-math.

Note that with FP math, especially with C, there are mainly two kinds of
people:

 - those who know and care about underflows, overflows and precision.
   They _sometimes_ also want exact IEEE semantics, but not necessarily.
 - those who don't, and don't want to, and just want fast code.

Why not make this easier for the user:

 - default to non-IEEE, but "reasonably safe". Allow optimizations that
   underflow or aren't precise to ULP - or optimizations that extend the
   range of calculations (ie keep things in "double" or "long double"
   longer than strictly allowed), but don't allow optimizations that can
   make the range of operations smaller (ie extra traps are bad).

 - make "-ffast-math" mean exactly that: fast.  Even at the expense of
   being even more incorrect, ie allowing optimizations that might
   overflow. Let's face it - they are quite rare, especially in code
   that doesn't care. Make "-ffast-math" be the generic "if you don't
   know, and if you don't care, use this option" for people who just
   want ultimate speed for their quake3 thing.

 - make the people who _do_ know what they are doing and _do_ know what
   the options mean have extra options on just how careful they can be.
   It's silly and counter-productive to assume that most people would
   know what "-ffast-div" is.

So for real math, you'd have

 - "-mieee": This turns us into anal animals, and often implies using
   different math libraries etc too. No "reasonable safe" optimizations
   except the ones explicitly allowed by standards.

 - "-ffloat-precision": allow optimizations that might lose precision.

 - "-ffloat-div-reciprocal": allow optimizations with turning divides
   into reciprocals etc.

  ...

But don't make "-ffast-math" imply "it's still safe". Please. 

So do allow Honza's optimization under fast-math. Don't allow it by
default, and NEVER allow it with "-mieee" unless we start doign the
Fortran thing.

That way, we can also have a simple benchmarking rule: use "-O2
-ffast-math" for benchmarks. No need to tell people about the latest
"-ffloat-random-optimization" of the day, which changes with compiler
releases anyway.

		Linus