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

[Paul Zimmermann via libc-commits]

       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:

   fesetround(...);
   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:

FE_TONEAREST:
r=0x1.4cdc4c0000001p-6
FE_TOWARDZERO:
r=0x1.4cdc4bfffffffp-6
FE_UPWARD:
r=0x1.4cdc4c0000001p-6
FE_DOWNWARD:
r=0x1.4cdc4bfffffffp-6

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,
Paul