This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: PR29335 evaluate transcendentals@compile-time using MPFR
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.
Kaveh R. Ghazi email@example.com