This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] How to add vector math functions to Glibc
- From: Andi Kleen <andi at firstfloor dot org>
- To: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Sun, 21 Sep 2014 09:31:11 -0700
- 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>
Andrew Senkevich <email@example.com> writes:
> due to latest OpenMP and CilkPlus features supported in GCC vectorized
> math functions can be utilized more widely. So we need to find general
> way how to add vectorized math functions to Glibc.
> Lets discuss the following questions which were raised after first
> patch x86_64 specific was sent.
> 1. Should functions go in libm or a separate libmvec library?
I would just put them into libm. Simplifies things for everyone.
> 2. What requirements on the compiler / assembler versions used are imposed
> by the requirement that the ABI provided by glibc's shared libraries must
> not depend on the tools used to build glibc, and what such requirements is
> it OK to impose (it may be OK to move to GCC 4.6 as minimum compiler at
> present, but requiring a more recent version would be a problem; we'd need
> to consider what binutils version we can require)? If a separate libmvec
> is used, is it OK simply not to build it if those requirements aren't met?
Requiring newer binutils should be fine. I believe glibc has done that
in the past.
> (It's definitely not OK for the ABI of a library to vary incompatibly, but
> it might be OK for the presence of a library to be conditional.)
It would be even fine to leave out the symbols from a libm
in this case. The error message to the user should be of similar
quality as for a missing library (in fact likely better)
> 6. How do we handle different glibc versions having vectorized functions
> for different vector ISA extensions?
If your glibc does not not support what you compiled for the dynamic
linker will just error out. Seems reasonable to me.
> 7. Note that if we're relying on #pragma omp declare simd meaning a precise
> set of function versions are available - with a guarantee that no future
> compiler version will interpret is also meaning an AVX512 version is
> available, for example, so that it's safely possible to use older
I guess that would need an (new?) option to gcc to declare what it
can expect to be available in the library? With distributions
setting the default at gcc build time.