This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86-64: Optimize e_expf with FMA [BZ #21912]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Arjan van de Ven <arjan at linux dot intel dot com>, Carlos O'Donell <carlos at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, <nd at arm dot com>
- Date: Wed, 16 Aug 2017 17:11:55 +0000
- Subject: Re: [PATCH] x86-64: Optimize e_expf with FMA [BZ #21912]
- Authentication-results: sourceware.org; auth=none
- References: <6d943008-ffb1-af02-ddf3-f287fe99ff1f@redhat.com> <aedfbd8e-8973-ddff-9bbf-9eac89c1d633@linux.intel.com> <59945D11.3050908@arm.com>
On Wed, 16 Aug 2017, Szabolcs Nagy wrote:
> the idea is that the x86 asm has overkill
> precision (very close to 0.5 ulp error, but
> not correctly rounded), we can debate this
> later, but i think the polynomial can be
> reduced and there should not be much difference
I think that when choosing a level of accuracy for which to tune a
polynomial (when the function implementation is such that you can readily
choose the accuracy) it's reasonable to aim for a round-to-nearest result
that is the result of rounding the mathematical result up or down (which
implies the exact result when the mathematical result is exactly
representable), and a result in other modes that is either one of those
values, or the result of applying nextup or nextdown to one of them.
(This implies a round-to-nearest error of at most 1ulp in the terms in
which the libm-test infrastructure measures it, relative to a
correctly-rounded result, and an error in other rounding modes of at most
3ulp, normally at most 2ulp, in those terms.)
Correct rounding should explicitly not be a goal for libm functions not
bound to IEEE operations, and I'm doubtful of aiming for 0.501ulp errors
either.
--
Joseph S. Myers
joseph@codesourcery.com