ia64 libm update

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

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: libm.gnumeric
Description: libm measurements