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

[Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>]

2014-09-18 17:48 GMT+04:00 Andrew Senkevich <andrew.n.senkevich@gmail.com>:
> Lets discuss the following questions which were raised after first
> patch x86_64 specific was sent.

In x86_64 case Vector Function ABI
http://www.cilkplus.org/sites/default/files/open_specifications/Intel-ABI-
Vector-Function-2012-v0.9.5.pdf exists which GCC follows (with a
little differences) generating vector call.

> 1. Should functions go in libm or a separate libmvec library?

If integrate new functions with libm it will be easier for developers
to employ vectorization and should improve acceptance.
Libmvec case affects compiler options and it seems new header need to
be included instead of math.h, or is it OK include it in math.h?
But libmvec could be better from the side of optional build (mentioned
later in 2.) in case of addition most modern implementations.

> 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?
> (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.)

Addition of vectorized versions in currently existing in Glibc ISAs
may not affect build (f.e. SSE4, AVX, AVX2 in x86_64 case).
Most modern implementation imply necessary checks in configure and
hiding under according macros, another words it can have optional
build.

> 3. Should it be declared that these vectorized functions do not set errno?
> (If so, then any header code that enables them to be used must of course
> avoid enabling them in the default -fmath-errno case.)  Similarly, do they
> follow the other goals documented in the glibc manual for accuracy of
> results and exceptions (for all input values, including e.g. range
> reduction)?  If not, further conditionals such as -ffast-math may be
> needed.

For x86_64 these functions doesnât set errno and have less accuracy so we
need to require to set -fast-math (which sets -fno-math-errno) to use
them (or may be set -ffast-math under -fopenmp for x86_64).

> 4. We need to handle different architectures having different sets of
> functions vectorized.

We need to have some way for #pragma simd declare to be architecture dependent.
It gives possibility to have different sets of vectorized functions
for different architectures.

> 5. We need to handle different architectures possibly not having the
> same set of vector ISAs for each function.

If GCC requires all possible versions exist (as for x86_64 for now) we
can achieve it by wrappers.
If GCC can vectorize in only several ISAs for some architecture - we
need to have only that according implementations.

> 6. How do we handle different glibc versions having vectorized functions
> for different vector ISA extensions?

It seems it is became problem only if someone has old installed Glibc
version and binary with symbol from new Glibc version?

> 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
> with a newer compiler - there should be some sort of ABI document
> (preferably compiler-independent) stating that this is the meaning of that
> pragma on x86_64 and that this pragma says nothing about availability of
> function versions for other vector extensions and that if an ABI is
> defined for such versions in future, it will use a different pragma to
> declare their availability. Is there such an ABI document available that
> defines what this pragma means on x86_64?

To inform GCC from Glibc side we need to have some OpenMP extension
informing GCC about currently available ISAs.


--
WBR,
Andrew