This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Convert mantissa storage in mp_no to int
- From: Carlos O'Donell <carlos at systemhalted dot org>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 28 Jan 2013 13:56:57 -0500
- Subject: Re: [PATCH v2] Convert mantissa storage in mp_no to int
- References: <20121220191320.GD26426@spoyarek.pnq.redhat.com> <Pine.LNX.4.64.1212202034170.24913@digraph.polyomino.org.uk> <20121221021737.GF26426@spoyarek.pnq.redhat.com> <20121221024840.GA9870@spoyarek.pnq.redhat.com>
On 12/20/2012 09:48 PM, Siddhesh Poyarekar wrote:
> Hi,
>
> Here's v2 of the patch with the problem of truncation of an
> intermediate value fixed as Joseph pointed out. The code is not used
> by i386, so I couldn't test it to see it break and then fixed.
>
> Siddhesh
>
> ChangeLog:
>
> 2012-12-21 Siddhesh Poyarekar <siddhesh@redhat.com>
>
> * sysdeps/ieee754/dbl-64/mpa.c (I_RADIX): New macro.
> (TWOPOW): Likewise.
> (__acr): Juggle logic a bit to make it faster and use int
> instead of doubles.
> (__mp_dbl): Use int values instead of double.
> (__dbl_mp): Likewise.
> (add_magnitudes): Likewise.
> (sub_magnitudes): Likewise.
> (__add): Likewise.
> (__sub): Likewise.
> (__mul): Likewise.
> * sysdeps/ieee754/dbl-64/mpa.h (mp_no): Change type of D to int
> array.
> * sysdeps/ieee754/dbl-64/mpa.c (__mpatan): Use int values
> instead of double.
> * sysdeps/ieee754/dbl-64/mpatan2.c (__mpatan2): Likewise.
> * sysdeps/ieee754/dbl-64/mpexp.c (__mpexp): Likewise.
> * sysdeps/ieee754/dbl-64/mpsqrt.c (__mpsqrt): Likewise.
> * sysdeps/ieee754/dbl-64/mptan.c (__mptan): Likewise.
> * sysdeps/ieee754/dbl-64/sincos32.c (__c32): Likewise.
> (__mpranred): Likewise.
> * sysdeps/ieee754/dbl-64/sincos32.h (oofac27): Likewise.
> (pi): Likewise.
> (hp): Likewise.
> * sysdeps/ieee754/dbl-64/slowpow.c (__slowpow): Likewise.
This looks good to me.
Is Power using this code?
What does the performance look like there?
I'm getting more nervous of these kinds of micro-optimizations
in isolation without a global view of our libm performance.
I'd really like to see more progress on a libm micro-benchmark
that we can use to see how these changes impact *ALL* of the
functions in libm. At a minimum we need to test the inputs
identified in the current testsuite.
Cheers,
Carlos.