This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New insns for the s390 backend (2)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Bradley Lucier <lucier at math dot purdue dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 27 Aug 2003 12:19:12 -0600 (MDT)
- Subject: Re: New insns for the s390 backend (2)
On Wed, 27 Aug 2003, Bradley Lucier wrote:
> > Is there any reason to believe that -ffast-math isn't suitable for
> > over 95% of GCC's users?
>
> No.
Thanks. I just wanted to be sure that there weren't any glaringly
bad trnasformations in the code, or to worry users unduly.
> On rs6000 fmadd is enabled by default. I have no opinion about this.
> Enabling fmadd is compatible with IEEE 754 arithmetic, since IEEE 754
> does not say what happens you have operations involving more than two
> operands.
If fmadd where being added as target intrinsic such as __builtin_fmadd
I couldn't agree. However, as generic RTL patterns in the .md files
these will be used whenever CSE, GCSE or combine tries mushing two
expressions into one. i.e. if the programmer writes:
x = a * b;
y = x + c;
IEEE 754 has its opinions on rounding, but GCC will still manage to
use fmadd. Perhaps a safer approach is a __builtin_fmadd (perhaps
even on all platforms using a default mult-then-add implementation
when a special isnsn isn't available), and then guard the implicit
use of fmadd with flag_unsafe_math_optimization.
> In other parts of the code, using FFT for fast bignum arithmetic for
> example, I cannot tolerate flag_unsafe_math_optimizations (since that
> may introduce too large errors in the precomputed sine and cosine
> tables), but fmadd is just fine, since it actually reduces the errors
> when used. There is a beautiful paper by Colin Percival that gives
> relatively sharp global error bounds for FFTs, and the hypotheses are
> satisfied with our without fmadd, but the hypotheses are not satisfied
> if the sine/cosine tables are not accurate enough.
Ok, I'll read up some more on FFTs for bignum arithmetic. It was my
understanding that this was one area where fair amount of inaccuracy
was tolerated, but I guess the problem then becomes how much you can
get away with? Would -fno-builtin-cos and -fno-builtin-sin or the
use of -mno-fancy-math-387 help with your table construction?
Roger
--