This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Faster PPC rounding checks in libm?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "munroesj at linux dot vnet dot ibm dot com" <munroesj at linux dot vnet dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Mon, 21 Mar 2016 23:02:12 +0000
- Subject: Re: Faster PPC rounding checks in libm?
- Authentication-results: sourceware.org; auth=none
- References: <56F005BC dot 4050700 at linux dot vnet dot ibm dot com>
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