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

[Linus Torvalds <torvalds at transmeta dot com>]

On 31 Jul 2001, Gabriel Dos Reis wrote:
>
> What I intended to mean is that the compiler has, first, to prove that
> such transformmation yields the same result.

Ehh..

You're _wrong_.

A lot of compiler optimizations yield different results. The question is
whether it is acceptable or not.

It _clearly_ is acceptable to do when the user has explicitly asked for
"-ffast-math". The whole meaning of the flag is to say "I want it fast,
even if you might lose some range or precision".

It's only a matter of defining the semantics.

There are other optimizations like that. Signed integer overflow is
undefined, so you can optimize integer operations in ways that do not give
the same results for all integers.

Alias analysis was added several years ago, even though it was _clearly_ a
"illegal optimization" from a traditional C standpoint. That one broke
tons of real programs. Again, it was a question of re-defining the
semantics, and allowing people to take advantage of them.

Already, the _default_ behaviour for gcc at least on x86 with floating
point has very little to do with IEEE. It's been discussed several times
how to fix it - and very little real work on it has been done for the last
several years. Why? Because it really doesn't matter for most people, and
the current work-arounds are too much of a performance hit.

So gcc _already_ has "better fast than correct to the last ULP in IEEE".
Live with it. Even by default. Your argument that it cannot do the same
even when the user asks for it is completely ludicrous.

Your continual insistence that it is "wrong" only shows that you have
built a cage around your brain.

Have you even _looked_ at what the gcc definition for "fast-math" are?
Look again:

  {"fast-math", &flag_fast_math, 1,
   "Improve FP speed by violating ANSI & IEEE rules" },

and realize that even something simple as "double" doesn't historcially
have an exact meaning in C (ie you can _not_ assume specific ranges or
specific IEEE rounding in traditional C - it was left up to the
implementor to do as best he could with what hardware was available).

That means that traditionally, you don't even know what overflows or not,
or what precision you get. It's historically "undefined". Which means that
the semantics are not clear.

Now, this is obviously why a lot of computational people disliked,
distrusted and didn't use C historically, preferring to use Fortran which
had more defined rules. And which is, of course, why C99 integrated the
math extensions that some people have been working on for a loong time.

But you have to realize that this is (a) fairly recent and (b) not
everybody needs or wants it.

And you should also realize that YOU are not the grand poobah that gets to
tell people what semantics they want.

[ Neither am I, of course, but I'm arguing for choice and freedom, while
  you're arguing for small-mindedness everywhere. ]

			Linus