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

[Kevin Handy <kth at srv dot net>]

dewar@gnat.com wrote:
> 
> <<Can we please take it as given that no transformation will be applied
> without something at least vaguely resembling a rational argument that
> it could be an actual optimisation?
> >>
> 
> Once you allow a compiler to make transformation X, then the interaction
> of transformations is often such that the idea of "rational argument" is
> highly dubious. I already gave an argument showing why it is perfectly
> believeable that a compiler would transform
> 
> a / b
> 
> into
> 
> (a*K) / (b*K)

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.

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".

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.

Showing a transform is broken by using an interation with a
broken transform is also not helpful. You might as well argue that
if "a+b" were optimized to "a*b", then "x+y/1.0" could be
transformed into "x*y", therefor you can't translate "a/1.0"
into "a".

What if the compiler translated "(a*K) / (b*K)" into "a/b".
This is a much more likely transformation the optimizer might
make than the former. Problems with that transform would be
more intresting and useful.

> Sure, it is a somewhat unlikely combination of circumstances, but if there
> is one thing that anyone who has worked on optimizing compilers knows, it is
> that unlikely combinations of things do happen in ways that are often very
> hard to anticipate, and optimzers are not in the business of "well this
> speeds up most programs, and miscompiles others, but we can't tell you
> the difference".

I'd really like to know of possible problems in normal calculations,
instead of those that are trying to push the FPU against its limits 
(where they shouldn't be using fast-math anyway). And problems with 
interactions in the proposed optimizations, not interactions with 
possible future ones that are broken by themselves.

[I'm really not trying to sound nasty in this e-mail, just hoping to
learn about real problems with proposed optimizations, not about 
broken non-proposed transformations]