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*: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>*To*: "Joseph S. Myers" <joseph at codesourcery dot com>*Cc*: gcc-patches at gcc dot gnu dot org*Date*: Wed, 11 Oct 2006 23:56:45 -0400 (EDT)*Subject*: Re: [PATCH]: PR29335 evaluate transcendentals@compile-time using MPFR*References*: <Pine.GSO.4.58.0610070941240.6946@caipclassic.rutgers.edu> <Pine.LNX.4.64.0610071728420.30039@digraph.polyomino.org.uk>

On Sat, 7 Oct 2006, Joseph S. Myers wrote: > On Sat, 7 Oct 2006, Kaveh R. GHAZI wrote: > > > Here's a proof-of-concept patch for PR middle-end/29335, evaluating > > transcendental functions at compile-time using MPFR. > > > > It'll depend on whether we include GMP/MPFR in the GCC repository as > > discussed here. We either need to do that or add configure goo to detect > > if we have MPFR. I'm in favor of including GMP/MPFR (but I need help!) > > http://gcc.gnu.org/ml/gcc/2006-10/msg00136.html > > > > The patch also needs testcases and more builtin functions to be converted. > > So far it does sin, cos and tan. But I made it very easy to add more, you > > only need a couple of lines of code for each one. The bulk of the work is > > done in do_mpfr_arg1 which should satisfy all one-argument math builtins. > > We can use it as a template for a do_mpfr_arg2 function for two-argument > > builtins when we do pow, etc. > > > > Thoughts? > > I think doing this is a good idea. > > If -frounding-math then it would be safest to disable the folding unless > MPFR tells you that the result is exact for that particular argument. > This is probably more significant for sqrt than for the transcendental > functions, since sqrt is an IEEE 754 operation that should follow the > rounding mode. I think switching the sqrt implementation to use MPFR > would be a good idea, since the present one may not get the last bit right > for IEEE quad long double. I'm not sure checking whether MPFR got an exact result is any safer because MPFR is calculating the result with more precision than the target has, then passing that to build_real() with the relevant type. So the value may get truncated and will be no longer "exact". I may have to punt on -frounding-math always, unless we can guarantee the result was exact within the precision of the requested target type. Thanks, --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu

**References**:**[PATCH]: PR29335 evaluate transcendentals at compile-time using MPFR***From:*Kaveh R. GHAZI

**Re: [PATCH]: PR29335 evaluate transcendentals at compile-time using MPFR***From:*Joseph S. Myers

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

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