Activate -mrecip with -ffast-math?

[Giovanni Bajo]

On 6/18/2007 12:16 PM, tbp wrote:

>> Of course there are cases with every optimization enabled by 
>> -ffast-math that
>> can break existing programs.  Just that we know of one case beforehand 
>> shouldn't
>> prevent us from enabling -mrecip at -ffast-math (provided -mno-recip
>> still works,
>> regardless if provided before or after -ffast-math).  [We'll at least
>> get some more
>> testing coverage this way]
> Argh! Please do not make -ffast-math even more of a pain to work with
> than it is already.
> You have to enable it, on the whole compilation unit, to get anywhere
> near decent performance; there's no escape: either you do not turn it
> on and everything slows to a crawl, or you pay for not being able to
> inline from another unit.
> 
> Until now, the contract was: you have to deal with (and contain) NaN
> and infinities. Fair enough, even if tricky that remained manageable.
> But if i can't expect a mere division by 0, or sqrt of 0 (quite common
> with FTZ/DAZ on) to give me respectively an infinite and 0 and instead
> get a NaN (which i can't filter, you remember?) because of the NR
> round, that's pure madness.
> 
> So please, for the love of everything's sacred, leave such stunts out
> of  -ffast-math.

I understand your problems, but let me state that your objections are 
totally subjective. *You* need a specific behaviour from -ffast-math 
(eg: keep NaN/Inf), but that's not what *I* need. So, we have different 
goals.

Both you and me can still get what they need from GCC by using more 
fine-grained options (you probably want -fno-finite-math or something 
like that, and I want -mrecip).

Both our goals are legitimate. But that's not the point. The point is 
what -ffast-math semantically means (the simplistic list of suboptions 
activated by it is of couse unsufficiente because it doesn't explain how 
to behave in face of new options, like -mrecip). My proposal is:

"-ffast-math activates all the mathematical-related optimizations that 
improves code speed while destroying floating point accuracy."

If you have a different proposal, please provide your own statement. 
Saying "-ffast-math provides all the optimizations which are not a pain 
to work with" obviously isn't acceptable.
-- 
Giovanni Bajo