This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] How to add vector math functions to Glibc


Hi all,

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?

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

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.

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

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

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

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?



--
WBR,
Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]