Faster PPC rounding checks in libm?

Faster PPC rounding checks in libm?

[Paul E. Murphy]

I'm looking at trying to recover a bit of performance from the transcendental
functions within libm. The mffs/mtfs instructions used to check the rounding
mode create a substantial bottleneck (see PowerISA 2.07B 4.6.10). From what
I can tell, most of these functions just need to ensure they are computed in
round to nearest.

One thought is to compute known values to infer whether the core is already
in round to even. Though, it has the drawback of always raising the inexact
exception. So, such a check is not an acceptable replacement for all uses.

How objectionable is it to add a rounding check which is allowed to raise
inexact for math functions which the inexact behavior is unspecified?

Re: Faster PPC rounding checks in libm?

[Joseph Myers]

On Mon, 21 Mar 2016, Paul E. Murphy wrote:

> I'm looking at trying to recover a bit of performance from the transcendental
> functions within libm. The mffs/mtfs instructions used to check the rounding
> mode create a substantial bottleneck (see PowerISA 2.07B 4.6.10). From what
> I can tell, most of these functions just need to ensure they are computed in
> round to nearest.
> 
> One thought is to compute known values to infer whether the core is already
> in round to even. Though, it has the drawback of always raising the inexact
> exception. So, such a check is not an acceptable replacement for all uses.
> 
> How objectionable is it to add a rounding check which is allowed to raise
> inexact for math functions which the inexact behavior is unspecified?

Well, none of the transcendental functions have specified results for 
"inexact" for non-NaN arguments.  So provided the rounding mode is set 
only after NaN arguments have been dealt with, checking that way seems 
reasonable in those functions.  Of course it's *not* valid to define the 
public fesetround function that way.  And you need to make clear, in the 
comments on the generic definitions of the relevant (new) macros in 
sysdeps/generic/math_private.h, that it's possible the macro may raise 
spurious "inexact".

In fact the bulk of the existing cases setting FE_TONEAREST are in 
transcendental functions (whether they do it only after NaN arguments are 
handled, I haven't checked).  (Exceptions for dbl-64 are in sqrt and fma, 
calling libc_feholdexcept_setround and caring about exact exceptions, and 
for both of those the generic implementation isn't used for Power anyway.)  
This gives rise to a question of whether to add new macros / functions for 
the spurious-inexact-OK cases or to adjust the semantics of the existing 
interfaces and add new ones for the cases that can't have spurious 
inexact; adding new macros for spurious-inexact-OK is at least safer.

-- 
Joseph S. Myers
joseph@codesourcery.com