This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*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 --

**Follow-Ups**:**Re: New insns for the s390 backend (2)***From:*Bradley Lucier

**Re: New insns for the s390 backend (2)***From:*Richard Henderson

**Re: New insns for the s390 backend (2)***From:*Gabriel Dos Reis

**References**:**Re: New insns for the s390 backend (2)***From:*Bradley Lucier

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |