Re: Activate -mrecip with -ffast-math?

[Giovanni Bajo <rasky at develer dot com>]

On 17/06/2007 20.20, Uros Bizjak wrote:

> > I was wondering if there are objects to automatically activating Uros' 
> > new -mrecip flag when -ffast-math is specified. It looks like a good 
> > match since -mrecip is exactly about fast non-precise mathematics.
>
> There is a discussion in gcc-patches@ mailing list about this topic, in 
> "Re: [PATCH, middle-end, i386]: reciprocal rsqrt pass + full recip x86 
> backend support" thread [1]. The main problem is, that one of the 
> polyhedron tests segfaults with this patch (not the problem of the recip 
> patch, but usage of questionable FP equivalence tests and FP indexes in 
> the array).

My own humble 2c on this is that what Roger Sayle calls "the black & white 
approach" is what most users understand. I am no expert of floating point 
arithmetics standard; I do understand that by default GCC is very accurate to 
the standards, and that -ffast-math is the option for "less accuracy, more 
speed". Simple users have simple needs.

I reckon simple users like me want an option that means: "activate all options 
that speed up floating point calculations at the cost of accuracy". I believe 
that option is "-ffast-math" today. If that's the semantic of the option, then 
-mrecip should be added to it.

But if you dispute this, and you believe that the current semantic of 
"-ffast-math" is different (that is: there are track records of -ffast-math 
only including a selection of optimizations by some standards -- like -O2 
which doesn't mean "every optimization"), that's fine by me either. But 
please, give me a -ffaster-math or -fuber-fast-math that really means "turn on 
everything, thanks".

Either way, -ffast-math should be documented to explain its intended semantic, 
and not only how that semantic is currently implemented in GCC. This way, this 
discussion will not need to be reopened in the future.
--
Giovanni Bajo