Re: [RFC] How to add vector math functions to Glibc

[Andi Kleen <andi at firstfloor dot org>]

Andrew Senkevich <andrew.n.senkevich@gmail.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
> glibc

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.

-Andi