This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][stage2 project] Sub-Target specific math routines library
On Wed, 18 Jan 2006, Gabriel Dos Reis wrote:
> Richard Guenther <rguenther@suse.de> writes:
>
> | This patch implements suggestions from Joseph (document
> | --enable-libgcc-math) and Gaby (change name to libgcc-math) and cuts
> | the library size down by not using wrapper .c files but instead using
> | -include.
>
> Thanks!
>
> |
> | Instead of including the flt-32 and dbl-64 (I retained these directory
> | names because in future we may import ldbl-128 and ldbl-96) I attached
> | the diffs to the upstream glibc versions.
>
> OK. To what extent the names you retains here conflict with glibc's?
Well, I don't understand what you are after here - the filenames are
the same as in glibc, but this can't matter. One reason not using
flt, dbl and ldbl is that we have two ldbl (ldbl-96 and ldbl-128).
But I don't feel very strong here.
> | This was bootstrapped and regtested on x86_64-unknown-linux-gnu and
> | i686-pc-linux-gnu.
> |
> | A drop-in tarball can be found at
> | http://www.suse.de/~rguenther/libgcc-math.tgz
> |
> | The parts of the first patch that touched gcc/ to do the spec file
> | fiddling have been moved to the libgcc-math using patch as they seemed
> | unrelated enough to the addition of libgcc-math at the toplevel.
> |
> | Ok for mainline?
>
> The patch almost satisfies me (see below), but you'd need a build
> machinery maintainer approval for the configury bits.
>
> [...]
>
> | + # Set the default so we build libgcc-math for ix86 and x86_64
> | + case "${target}" in
> | + i?86-*)
> | + libgccmdefault=yes ;;
> | + x86_64-*)
> | + libgccmdefault=yes ;;
> | + *)
> | + libgccmdefault=no ;;
>
> s/libgccmdefault/libgcc_mathdefault/?
Ok.
> | + esac
> | + AC_ARG_ENABLE(libgcc-math,
> | + [ --enable-libgcc-math Builds libgcc-math directory],
> | + ENABLE_LIBGCCM=$enableval,
> | + ENABLE_LIBGCCM=$libgccmdefault)
>
> s/LIBGCCM/LIBGCC_MATH/?
Ok. (They are just local shell temps, but for consistency I'll change
them)
> [...]
>
> | + AC_PREREQ(2.59)
> | + AC_INIT(libgccm, 1.0)
>
> s/libgccm/libgcc-math/
Right - this one I missed.
> [...]
>
> | + #ifndef LIBGCCM_ENDIAN_H
> | + #define LIBGCCM_ENDIAN_H
>
> Once this patch is in, we should have there infered from the target
> configuration so that we don't have many places duplicating the same
> information.
Sure. For now we need it only in i386/
> [...]
>
> | + LIBGCCM_1.0 {
>
> I expected this to be LIBBGCC_MATH_1.0
Ok.
> | + global:
> | + __libm_sse2_acos; __libm_sse2_asin; __libm_sse2_atan2; __libm_sse2_atan;
> | + __libm_sse2_exp; __libm_sse2_log; __libm_sse2_log10; __libm_sse2_log;
> | + __libm_sse2_pow; __libm_sse2_cos; __libm_sse2_sin; __libm_sse2_tan;
> | + __libm_sse2_acosf; __libm_sse2_asinf; __libm_sse2_atan2f;
> | + __libm_sse2_atanf; __libm_sse2_cosf; __libm_sse2_expf; __libm_sse2_log10f;
> | + __libm_sse2_logf; __libm_sse2_powf; __libm_sse2_sinf; __libm_sse2_tanf;
> | + local:
>
> I'm wondering why these symbols won't conflict with ones installed on
> the target.
The symbol names were chosen after the ones Intel chose with their libimf
library. They do not conflict with anything in glibc libm, and I don't
expect any other library providing them. I.e. I see that the canonical
symbol names would be __libgcc_math_sse2_*, but for the reason that I
could benchmark libgcc-math against libimf without changing anything but
LD_LIBRARY_PATH was a good enough reason. Also I remember RTH agreeing
to the choice of the symbol names.
Richard.