This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix powerpc fmax, fmin sNaN handling (bug 20947) [committed]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Fri, 16 Dec 2016 17:41:58 +0000
- Subject: Re: Fix powerpc fmax, fmin sNaN handling (bug 20947) [committed]
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1612150043400.25901@digraph.polyomino.org.uk> <1481908789.12005.20.camel@oc7878010663>
On Fri, 16 Dec 2016, Steven Munroe wrote:
> > This patch fixes the powerpc versions of these functions (shared by
> > float and double, 32-bit and 64-bit). The structure of those versions
> > is that all ordered cases are already handled before anything dealing
> > with the case where the arguments are unordered; thus, this patch
> > causes no change to the code executed in the common case (neither
> > argument a NaN).
> >
> This patch, as is, will cause a sever performance regression for
> power6/7/8 and should be fixed or reverted before 2.25 freezes.
A general assumption in libm functions is that NaN inputs are an uncommon
case and performance for NaN inputs is not of much importance; the code
for NaN inputs should just aim for correctness and simplicity. I think
people calling fmax or fmin generally want the maximum or minimum of two
finite numbers.
As I said, there is no change to the code executed for the normal case of
non-NaN inputs, so I see no reason for performance in the common case to
be affected. Of course performance improvements for the NaN case are
still welcome (and that sort of small local fix would seem perfectly
suitable to go in during the freeze if architecture maintainers think it
appropriate).
If the presence of this code for the NaN case somehow affects the
performance of non-NaN case, please let me know; it wasn't meant to do so.
--
Joseph S. Myers
joseph@codesourcery.com