This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] How to add vector math functions to Glibc
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>, Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 25 Sep 2014 15:43:27 -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> <87y4tdgckw dot fsf at tassilo dot jf dot intel dot com>
On 09/21/2014 12:31 PM, Andi Kleen wrote:
> 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.
I disagree, I think libmvec.so is the best choice.
Adding to libm.so adds features that we are very new to libm.so,
that we might need to fix, that not all users use. It is the perfect
candidate to start out as a distinct library.
Nothing prevents us from putting libmvec.so symbols into libm.so in
the future if this turns out to be what we want.
I argue for a conservative approach:
* limb.so as a linker script with AS_NEEDED for libmvec.so.
>> 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)
I'm not opposed, but I think it's overly complicated.
>> 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.
Either it errors out because the underlying symbols aren't there, or
it errors out because the object ISA and the runtime ISA don't match.
Note that we have no present support for the dynamic loader to detect
runtime ISA mismatch. We have some support for this in the static
linker via .gnu_attributes. It would be nice to have some fast bit-mask
checking at runtime to detect invalid objects being loaded.
Note that the ld.so.cache takes care of some of this, and that's used
to filter out libraries you shouldn't be able to load. Yet if the cache
isn't populated you still search and load whatever is on disk.
>> 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.
I don't understand this question.