[libc-commits] [PATCH] D115828: [libc] Implement correctly rounded log2f based on RLIBM library.

Paul Zimmermann via libc-commits libc-commits at lists.llvm.org
Thu Dec 23 21:17:31 PST 2021

       Dear Santosh,

> Date: Thu, 23 Dec 2021 17:37:50 +0000 (UTC)
> From: Santosh Nagarakatte via Phabricator <reviews at reviews.llvm.org>
> Dear Paul,
> I was wondering how you are testing other rounding modes other than round-to-nearest-ties-to-even.

as follows:

   y = log2f (x);

> The coefficients that we are using are identical.
> double r = __llvm_libc::fputil::polyeval(
>   d, extra_factor, 0x1.71547652bd4fp+0, -0x1.7154769b978c7p-1,                                                                                                           
>   0x1.ec71a99e349c8p-2, -0x1.720d90e6aac6cp-2, 0x1.5132da3583dap-2);    
> Now this double value "r" needs to be rounded according to the target rounding mode.
> The cast on line 142 in the current patch is doing static_cast<float>(r). I assume it is just rounding it to round-to-nearest ties to even.
> I am seeing that these coefficients are producing correctly rounded results for the round-to-nearest-ties-to-even.
> Further when the double value is specifically rounded to the target rounding mode, it is producing the correctly rounded results for them.
> If  possible, can you tell me the double value (r) returned by the libc polynomial with the above coefficients for various rounding modes corresponding to the  input  (x=0x1.03a16ap+0)?
> It should produce the same double value "r" for all rounding modes.
> In my build, it produces r = 0x1.4cdc4c80p-6, which when rounded to any rounding mode produces the correctly rounded result.

here is what I get with the different rounding modes:


The double value r differs because the rounding mode is also used internally
(for example for the polynomial evaluation).

The code could set internally the rounding mode to FE_TONEAREST, and
restore it before the last rounding, this would solve the issue (at least
for that x-value), but I guess that would be slower than dealing with one
exceptional case.

Best regards,

More information about the libc-commits mailing list