This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] How to add vector math functions to Glibc
- From: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 30 Sep 2014 22:40:12 +0400
- Subject: Re: [RFC] How to add vector math functions to Glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3tjquzniXP1weqxSVFJyhXqsf2PHuyrrrmqp7K0ZzORqA at mail dot gmail dot com> <CAMXFM3sGMNX1DEPAMt7qUR4UREF_xUAQjCG1OjBiZH2aoOFiPA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409181551370 dot 31607 at digraph dot polyomino dot org dot uk> <CAMXFM3tO7MTYCq8-YFZacdbLvR4iAab_n04AuB+rp2Phs4BvQg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409242011260 dot 7597 at digraph dot polyomino dot org dot uk> <CAMXFM3tqiqUNuSU2KXvAFM-QescX3+6xUO9=z5X0Ac6C9qJ7zg at mail dot gmail dot com> <CAMe9rOq7bZHb8R=opUzSmAMGWjLpX21mR=Sx96cuBph=TTtDXA at mail dot gmail dot com> <54246CB5 dot 7020908 at redhat dot com> <CAMe9rOoLmJ2jHWmERoB0M83WNKovJOgh0--Kquw9O86A1tPU0g at mail dot gmail dot com> <5424733D dot 6010305 at redhat dot com> <CAMe9rOpacze055qyBFzz3M-b-GNtXCqZzMmkScBL9a94zVj28g at mail dot gmail dot com> <54247FAB dot 6050002 at redhat dot com> <CAMXFM3v8narOLMHC5U=fvyTFWV6s4ZACN-UrAC4fAcUs9SOFfA at mail dot gmail dot com> <54257507 dot 9070508 at redhat dot com> <CAMXFM3vOLspQtHxgJfD_Emht480w2RMbiwnEH6A_LhoS-JZFag at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409301620020 dot 15186 at digraph dot polyomino dot org dot uk>
2014-09-30 20:35 GMT+04:00 Joseph S. Myers <firstname.lastname@example.org>:
> On Tue, 30 Sep 2014, Andrew Senkevich wrote:
>> diff --git a/configure.ac b/configure.ac
>> index 82d0896..c5c1758 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -903,7 +903,7 @@ LIBC_PROG_BINUTILS
>> # Accept binutils 2.20 or newer.
>> AC_CHECK_PROG_VER(AS, $AS, --version,
>> [GNU assembler.* \([0-9]*\.[0-9.]*\)],
>> - [2.1[0-9][0-9]*|2.[2-9][0-9]*|[3-9].*|[1-9][0-9]*], AS=:
>> critic_missing="$critic_missing as")
>> + [2.1[0-9][0-9]*|2.[2-9][2-9]*|[3-9].*|[1-9][0-9]*], AS=:
>> critic_missing="$critic_missing as")
>> AC_CHECK_PROG_VER(LD, $LD, --version,
>> [GNU ld.* \([0-9][0-9]*\.[0-9.]*\)],
>> [2.1[0-9][0-9]*|2.[2-9][0-9]*|[3-9].*|[1-9][0-9]*], LD=:
>> critic_missing="$critic_missing ld")
> Any change to required versions needs to include an update to install.texi
> (and the generated INSTALL file). It should also be proposed in a
> separate thread whose subject describes what is being proposed.
I thought it is already agreed in
But if separate thread is required I can start it.
>> +# We need to install libm.so as linker script
>> +# for more comfortable use of vector math library.
>> +subdir_install: $(inst_libdir)/libm.so
>> +$(inst_libdir)/libm.so: $(common-objpfx)format.lds \
>> + $(common-objpfx)math/libm.so$(libm.so-version) \
>> + $(common-objpfx)mathvec/libmvec.so$(libmvec.so-version) \
>> + $(+force)
>> + (echo '/* GNU ld script */';\
>> + cat $<; \
>> + echo 'GROUP ( $(slibdir)/libm.so$(libm.so-version) ' \
>> + 'AS_NEEDED ( $(slibdir)/libmvec.so$(libmvec.so-version) ) )' \
>> + ) > $@.new
>> + mv -f $@.new $@
> Do you have ordering issues here? It seems bad for math/ to install a
> direct symlink and then mathvec/ to change it to something else - all
> installation rules for libm should be in the math/ directory.
It must be in another Makefile of course.
> Do you need to link libmvec against libm (and if so, I'd expect associated
> Makefile rules, and maybe a Depend file to ensure the directories are
> built in the right order)?
Libmvec contains calls to scalar version from libm, but not supposed
to be used directly.
Is it ok not to link libmvec against libm in this case?
> Also, I'm not sure the empty libmvec option for unsupported architectures
> when we consider the case where functions require GCC or binutils versions
> newer than we wish to require, so they are optional on some architecture.
> I think having libmvec built or not built on that architecture, depending
> on the tools installed, is better than possibly having it built but empty
> if the tools are too old.
If library is empty but headers installed it will cause compilation
fail with according options.
Is it OK to add configure option enabled by default on x86_64 and
disabled on unsupported architectures?
> Did the patch pass the testsuite? If so, you have a problem - you didn't
> add ABI test baselines for this library (in this version, a default empty
> baseline, and one in sysdeps/unix/sysv/linux/x86_64), so the ABI tests
> should have failed, and you need to find out why they didn't run for this
> library, and fix that. If it failed for lack of ABI test baselines, add
Patch didn't pass the testsuite (even I don't mean it as patch, just as RFC).
The following will be added:
diff --git a/sysdeps/unix/sysv/linux/x86_64/64/libmvec.abilist
new file mode 100644
@@ -0,0 +1 @@
+ GLIBC_2.21 A
+ _ZGVdN4v_cos F
>> +#if defined __x86_64__ && defined __FAST_MATH__
>> +# define __DECL_SIMD_AVX2
>> +# define __DECL_SIMD_SSE4
> I don't see the need for this initial define to empty and subsequent
> #undef. Except you should probably have comments explaining exactly what
> these macros mean in terms of what function versions they define to be
If one function added it affects addition of 2 lines (both OpenMP and
Cilk Plus cases),
in this case it affects addition of only one line.