This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav: Message Nav: [Date Index] [Subject Index] [Author Index] [Thread Index] [Date Prev] [Date Next] [Thread Prev] [Thread Next]

# Re: What is acceptable for -ffast-math? A numerical viewpoint

• To: gcc at gcc dot gnu dot org, kth at srv dot net
• Subject: Re: What is acceptable for -ffast-math? A numerical viewpoint
• From: dewar at gnat dot com
• Date: Mon, 6 Aug 2001 21:50:53 -0400 (EDT)

```<<If gcc does this transformation without knowing a lot
about all of the numbers, then I'd suggust disabling it.
Does it do this with integers? I'd really hope not.
>>

No, of course not, this would be an invalid transformation for integers,
and no one would argue otherwise.

For reals, it is not so clear that everyone argues against such transformations
and in particular, if you really think that any transformation that is valid
for real arithmetic is OK, your viewpoint is not clear on this particular
issue (yes I know the "but don't do anything absurd" exception, but I don't
know how to define that, yet alone implement it :-)

<<It would make even less sense if you allowed K to go to zero.
You could then transform any division using this optimization
through the steps "a/b" => "(a*K)/(b*K)" => "(a*0)/(b*0)" =>
"0/0".
>>

Of course the transformation is invalid if K = 0.0, because then the
transformation is not valid in real arithmetic. Optimizers have to prove
necessary preconditions before they blindly do transformations!

<<If you allow a transform like this, you would also have to allow
a transform of "(a/K) / (b/K)", which is essentially the same
transform (just invert the constant). Now allow K to go to 0,
or to infinity.
>>

Again, I didn't bother to be explicit in my earlier note, because I
thought it was obvious, but I was only talking about cases where K
is non-zero and finite, since otherwise the transformation is just
plain wrong in both real arithmetic and floating-point arithmetic.

Let's at least assume (please let this be right) that no one proposes
a transformation that is valid in neither the floating-point model
being used, nor in real arithmetic?

```

Index Nav: Message Nav: [Date Index] [Subject Index] [Author Index] [Thread Index] [Date Prev] [Date Next] [Thread Prev] [Thread Next]