[PATCH] Evaluate pow(x,n) at compile-time
Joseph S. Myers
jsm28@cam.ac.uk
Mon Apr 14 20:15:00 GMT 2003
On Mon, 14 Apr 2003, Roger Sayle wrote:
> Unfortunately, the algorithms used by unbounded precision math libraries
> are often inappropriate for bounded precison representations. One word:
> "rounding". Even with fixed precision representations, many algorithms
> are not transferable, so almost all of glibc's implementations that are
> based upon IBM's high-precision math library can't be used for GCC's
> 160 bit representation. Issues such as the number of terms required in
> Chebychev and Remez approximations are parameterized on mantissa size.
Getting correctly rounded values (which glibc doesn't claim to do for all
functions) does in general need unbounded precision implementations; only
for a few functions is it provable that a given small bound on the number
of bits used suffices. (And I haven't yet seen a justification of why the
sqrt implementation in GCC should work in general using fewer than that
number of bits.) MPFR does various computations by computing an
approximation to some good precision with an error bound, then computing
to longer precisions as needed if the chosen precision wasn't enough to
determine the correct rounding, until the precision used is big enough;
doing some functions correctly would require GCC to do the same. It does
also make a choice of algorithm from various alternatives according to the
precisions involved.
> different from the one used by gmp's mpz/n_pow_ui.c. Different issues
> such as register usage, readability, performance, accuracy etc...
> impact the prefered method to choice.
For constant folding in GCC I claim we should first be accurate (correctly
rounded) if we fold at all and only then consider the other factors (which
might be relevant to whether we do fold a particular function at all).
When it's algorithmically possible to compute accurate values of pow(), we
should do so rather than providing less accurate values under -ffast-math
only.
> First, let me state I'm completely happy with RTH's patch. The improved
> real accuracy is worth the slightly slower compiler. However, I suspect
> that switching to "gmp", which was never intended to minimize memory
> footprint) really would be prohibitive.
You could use the existing code for the basic + - * / arithmetic
operations only, which should be all that occur in a bootstrap, and
convert to/from GMP format when doing operations that may need higher
precision than GCC's internal representation provides (including sqrt,
from the information so far provided).
--
Joseph S. Myers
jsm28@cam.ac.uk
More information about the Gcc-patches
mailing list