ia64 libm update

ia64 libm update

[David Mosberger]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 3101 bytes --]

A patch to update the ia64 libm can be found at:

 ftp://ftp.hpl.hp.com/pub/linux-ia64/libc-intel-libm-v2.1-update-041118.diff.gz

 md5sum: 97d9f77e79a0936271bdcdce593c9598

The patch is fairly big (slightly less than a meg, compressed) so I
didn't want to clutter your inbox.

This patch should be applied like so:

	$ cd libc
	$ zcat libc-intel-libm-v2.1-update-041118.diff.gz | patch -p0 -E

The "-E" is important here to ensure that empty files get removed.

The original motivation for pursuing this patch was to fill in the
missing routines (exp2l and log2l) but as I was looking at the code, I
noticed that the entire libm has fallen horribly behind the latest
release from Intel.  As far as I can tell, the libm currently in glibc
is based on v1.3 and the current release is v2.1.  Many improvements
in terms of accuracy, speed, and coverage have been made after v1.3.

To reduce the amount of effort to integrate the Intel libm into glibc,
I wrote a few scripts which take the original libm sources and massage
them such that they're usable in glibc (see the README in
sysdeps/ia64/fpu for details).  To make this fully automatic (and to
fix some minor bugs), I created a separate patch for the v2.1
distribution of libm.  This (small) patch can be found at:

 ftp://ftp.hpl.hp.com/pub/linux-ia64/intel-libm-041118.diff.gz

The hope is that these changes will be folded in by Intel eventually.

NOTE: The intel-libm-041118 patch is only needed if you want to
regenerate the sources from the pristine Intel sources---I'm
mentioning it here mainly for the sake of completeness.

I did the following testing on the libm that results from applying the
first patch in CVS libc:

 - "make check" results in no errors (with gcc-3.4; some gcc-3.3 have
   problems with the Bessel functions, but that's true for the old
   libm, too)

 - Ran the "import_check" script, which verifies that:

    (a) the name space is clean: any (imported) assembly file with
	multiple entry points must define only symbols that are weak
	or start with `__', and

    (b) the size of the data object symbols adds up to the size
        of the .rodata section

 - Verified that the new libm exports the exact same entry-points as
   the old one.

In terms of performance, the improvement is quite dramatic.  Most
functions are on the order of 20-50% faster.  Some (e.g., atanhf,
exp2f, exp2, log2f, log2, and tgammaf) are 80% faster, that is they
run in a fifth of the time they did before!

For completeness, I appended a gnumeric spreadsheet which shows the
results for many libm functions.

Note: The Bessel functions (j0f-y1l) _appear_ to be slower in the new
      libm.  However, this difference is entirely due to using gcc-3.4
      instead of gcc-3.3.  Indeed, the above patch doesn't touch the
      Bessel functions at all---they continue to be based on the
      generic versions.

I tested this patch about as well as I could and believe it to be
solid.  I'd therefore appreciate if it could be checked in.

Last but not least, thanks to HJ Lu for tracking down & fixing a bug
in log1lp.

Enjoy,

	--david


[-- Attachment #2: libm measurements --]
[-- Type: application/x-gnumeric, Size: 8439 bytes --]

Re: ia64 libm update

[Jakub Jelinek]

On Thu, Nov 18, 2004 at 11:46:58PM -0800, David Mosberger wrote:
Content-Description: message body text
> A patch to update the ia64 libm can be found at:
> 
>  ftp://ftp.hpl.hp.com/pub/linux-ia64/libc-intel-libm-v2.1-update-041118.diff.gz
> 
>  md5sum: 97d9f77e79a0936271bdcdce593c9598

I think e.g. the reversal of
2002-06-05  Brian Youmans <3diff@gnu.org>

        * sysdeps/ia64/fpu/e_acos.S: Added text of Intel license.
...

might be a problem.  Also, I personaly don't think the cvs_id's in all
files are very useful, they will IMHO be just source of merge conflicts
unless -ko'ed.

	Jakub

Re: ia64 libm update

[David Mosberger]

>>>>> On Fri, 19 Nov 2004 09:38:41 +0100, Jakub Jelinek <jakub@redhat.com> said:

  Jakub> I think e.g. the reversal of
  Jakub> 2002-06-05  Brian Youmans <3diff@gnu.org>

  Jakub> * sysdeps/ia64/fpu/e_acos.S: Added text of Intel license.
  Jakub> ...

  Jakub> might be a problem.

Oops, that was not intentional.

  Jakub> Also, I personaly don't think the cvs_id's in all files are
  Jakub> very useful, they will IMHO be just source of merge conflicts
  Jakub> unless -ko'ed.

Good point.

I replaced the old patch with this one:

 ftp://ftp.hpl.hp.com/pub/linux-ia64/libc-intel-libm-v2.1-update-041119.diff.gz
 md5sum: 5b9341a15b3b3f5ef782da23713d6cfd

It should fix both problems.

Thanks,

	--david

Re: ia64 libm update

[David Mosberger]

The latest ia64 libm update patch is now available at:

 ftp://ftp.hpl.hp.com/pub/linux-ia64/libc-intel-libm-v2.1-update-041123.diff.gz
 md5sum: 51f780c07a7467281d038f49de33c8d9

The only difference compared to the previous version is that I removed
the temporary workaround for the tgamma() functions since HJ Lu's
patch to fix those routines has been checked in.  Thus, "make check"
again succeeds without any failures.

Please apply.

Thanks,

	--david

PS: For completeness, here is a diff between the previous and current
    version of the patch.

--- ../libc-intel-libm-v2.1-update-041119.diff	2004-11-19 11:50:50.000000000 -0800
+++ ../libc-intel-libm-v2.1-update-041123.diff	2004-11-23 19:00:01.525722394 -0800
@@ -157944,7 +157944,7 @@
 Index: sysdeps/ia64/fpu/w_tgamma.S
 --- /dev/null
 +++ sysdeps/ia64/fpu/w_tgamma.S
-@@ -0,0 +1,1839 @@
+@@ -0,0 +1,1835 @@
 +.file "tgamma.s"
 +
 +
@@ -159710,11 +159710,7 @@
 +.pred.rel "mutex",p7,p8
 +{ .mfi
 +(p7)  mov           GR_TAG = 259 // negative
-+#ifdef _LIBC
-+(p7)  frcpa.s0      f8,p0 = f0,f0	// Get QNaN, and raise invalid
-+#else
 +(p7)  frcpa.s0      f8,p0 = f1,f8
-+#endif
 +      nop.i         0 
 +}
 +{ .mib
@@ -159787,7 +159783,7 @@
 Index: sysdeps/ia64/fpu/w_tgammaf.S
 --- /dev/null
 +++ sysdeps/ia64/fpu/w_tgammaf.S
-@@ -0,0 +1,1332 @@
+@@ -0,0 +1,1328 @@
 +.file "tgammaf.s"
 +
 +
@@ -161046,11 +161042,7 @@
 +.pred.rel "mutex",p7,p8
 +{ .mfi
 +(p7)  mov           GR_TAG = 262 // negative
-+#ifdef _LIBC
-+(p7)  frcpa.s0      f8,p0 = f0,f0	// Get QNaN, and raise invalid
-+#else
 +(p7)  frcpa.s0      f8,p0 = f1,f8
-+#endif
 +      nop.i         0 
 +}
 +{ .mib
@@ -161123,7 +161115,7 @@
 Index: sysdeps/ia64/fpu/w_tgammal.S
 --- /dev/null
 +++ sysdeps/ia64/fpu/w_tgammal.S
-@@ -0,0 +1,4489 @@
+@@ -0,0 +1,4485 @@
 +.file "tgammal.s"
 +
 +
@@ -165438,11 +165430,7 @@
 +.pred.rel "mutex",p7,p8
 +{ .mfi
 +(p7)  mov           GR_Parameter_TAG = 256   // negative
-+#ifdef _LIBC
-+(p7)  frcpa.s0      f8,p0 = f0,f0	// Get QNaN, and raise invalid
-+#else
 +(p7)  frcpa.s0      f8,p0            = f1,f8 // Raise V flag
-+#endif
 +      nop.i         0 
 +}
 +{ .mfb

ia64 libm update broke nextafterl

[Jakub Jelinek]

On Tue, Nov 23, 2004 at 09:33:12PM -0800, David Mosberger wrote:
> The latest ia64 libm update patch is now available at:
> 
>  ftp://ftp.hpl.hp.com/pub/linux-ia64/libc-intel-libm-v2.1-update-041123.diff.gz
>  md5sum: 51f780c07a7467281d038f49de33c8d9

It seems that this update broke nextafterl:

#include <float.h>
#include <math.h>
#include <stdlib.h>

int
main (void)
{
  union { long double d; unsigned long int x[2]; } v;

  v.d = nextafterl (nextafterl (LDBL_MIN, LDBL_MIN / 2.0), LDBL_MIN);
  if (v.x[0] != 0x8000000000000000L)
    abort ();
  return 0;
}

or:

#include <float.h>
#include <math.h>
#include <stdlib.h>

int
main (void)
{
  if (nextafterl (nextafterl (LDBL_MIN, LDBL_MIN / 2.0), LDBL_MIN) != LDBL_MIN)
    abort ();
  return 0;
}

used to work before but now fails.
The first call to nextafterl is with:
f8             0        (raw 0x000000000000c0018000000000000000)
f9             0        (raw 0x00000000000000004000000000000000)
and returns on current CVS glibc:
f8             0      (raw 0x000000000000c0007fffffffffffffff)
while on stock 2.3.4:
f8             0        (raw 0x00000000000000007fffffffffffffff)

The second call gets with CVS glibc:
f8             0      (raw 0x000000000000c0007fffffffffffffff)
f9             0      (raw 0x000000000000c0018000000000000000)
but on 2.3.4:
f8             0        (raw 0x00000000000000007fffffffffffffff)
f9             0        (raw 0x000000000000c0018000000000000000)
and returns on CVS glibc:
f8             0      (raw 0x00000000000000004000000000000000)
while on 2.3.4:
f8             0        (raw 0x000000000000c0018000000000000000)

0x000000000000c0007fffffffffffffff doesn't sound like correct
denormal format.

The above test comes from test-misc.c, but there for some reason
GCC < 4 normalizes the values or something, but GCC 4 does not.
But the above distilled testcases fail with CVS glibc no matter
if -O0 or -O2 and no matter if using GCC 3.3.4, 3.4.3 or 4.0pre
and pass when moving the unmodified binaries to older glibc.

	Jakub