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
