* ia64 libm update @ 2004-11-19 7:47 David Mosberger 2004-11-19 8:43 ` Jakub Jelinek 0 siblings, 1 reply; 5+ messages in thread From: David Mosberger @ 2004-11-19 7:47 UTC (permalink / raw) To: libc-hacker [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ia64 libm update 2004-11-19 7:47 ia64 libm update David Mosberger @ 2004-11-19 8:43 ` Jakub Jelinek 2004-11-19 19:56 ` David Mosberger 0 siblings, 1 reply; 5+ messages in thread From: Jakub Jelinek @ 2004-11-19 8:43 UTC (permalink / raw) To: davidm; +Cc: libc-hacker 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ia64 libm update 2004-11-19 8:43 ` Jakub Jelinek @ 2004-11-19 19:56 ` David Mosberger 2004-11-24 5:33 ` David Mosberger 0 siblings, 1 reply; 5+ messages in thread From: David Mosberger @ 2004-11-19 19:56 UTC (permalink / raw) To: Jakub Jelinek; +Cc: davidm, libc-hacker >>>>> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ia64 libm update 2004-11-19 19:56 ` David Mosberger @ 2004-11-24 5:33 ` David Mosberger 2005-03-08 18:11 ` ia64 libm update broke nextafterl Jakub Jelinek 0 siblings, 1 reply; 5+ messages in thread From: David Mosberger @ 2004-11-24 5:33 UTC (permalink / raw) To: Jakub Jelinek, libc-hacker; +Cc: davidm 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* ia64 libm update broke nextafterl 2004-11-24 5:33 ` David Mosberger @ 2005-03-08 18:11 ` Jakub Jelinek 0 siblings, 0 replies; 5+ messages in thread From: Jakub Jelinek @ 2005-03-08 18:11 UTC (permalink / raw) To: davidm, hongjiu.lu; +Cc: libc-hacker 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-03-08 18:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-11-19 7:47 ia64 libm update David Mosberger 2004-11-19 8:43 ` Jakub Jelinek 2004-11-19 19:56 ` David Mosberger 2004-11-24 5:33 ` David Mosberger 2005-03-08 18:11 ` ia64 libm update broke nextafterl Jakub Jelinek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).