RE: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc

["Zamyatin, Igor" <igor dot zamyatin at intel dot com>]

> >
> > Please start by raising general design questions on libc-alpha before
> > sending any patches; only send patches once there is consensus on the
> > general questions and that consensus has been written up on a wiki page.
> 

Joseph, thanks for bringing all these items for discussion.

> I agree.
> 
> Please create a wiki page for this design writeup.
> 
> https://sourceware.org/glibc/wiki/
> 
> Create an account and I can add you to the editors list.
> 
> https://sourceware.org/glibc/wiki/EditorGroup

Created - IgorZamyatin

> 
> > For example:
> 
> > * Should functions go in libm or a separate libmvec library?
> 
> I do not thing adding these to libm is a good idea, and libmvec should be the
> right way forward, with coordination via the compiler driver to add -lmvec to
> these functions.
> 

No problem, we will make changes according this approach.

> > * 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.)
> 
> That's right. This patch has no configure checks that I can see, so how does it
> get built if the compiler or assembler doesn't support the required features?

Compiler is checked by _OPENMP macro.
As for assembler - I agree, we should add checks for different ISAs. 

> 
> > * 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.
> 
> I assume they follow the Intel documented definitions of these functions.
> 
> A pointer to those again would be helpful.

Will do.

> 
> > * How do we handle different glibc versions having vectorized
> > functions for different vector ISA extensions?  You're using a single
> > __DECL_SIMD, and having such a function only for AVX2.  But one glibc
> > version could have a function vectorized for ISA extensions A and B,
> > with another version adding it vectorized for C.  The compiler the
> > user uses with the installed glibc headers must be able to tell from
> > those headers which functions have what vectorized versions.  That is,
> > if a glibc version is released where _Pragma ("omp declare simd") is
> > used with a function that only has an AVX2 vectorized version, no past
> > or future GCC version can interpret that pragma as meaning that any
> > version other than AVX2 is available (it must be possible to use any
> > installed glibc headers with both past and future compilers).

We can require providing versions for all possible ISAs (we are going to do this for x86) so compiler should do all work itself.

Thanks,
Igor

> >
> > * Similarly, we need to handle different architectures having
> > different sets of functions vectorized and possibly not having the
> > same set of vector ISAs for each function.  Maybe this suggests having
> > an architecture-specific bits/ header that, for each function that
> > might be vectorized, defines a macro to tell the compiler what vector
> > versions are available.  E.g.
> >
> > #define __DECL_SIMD_COS_FLOAT /* empty */ #define
> > __DECL_SIMD_COS_DOUBLE __DECL_SIMD_AVX2 #define
> > __DECL_SIMD_COS_LONG_DOUBLE /* empty */
> >
> > where the declaration of cos automatically uses
> > __DECL_SIMD_COS_DOUBLE, and __DECL_SIMD_AVX2 expands to a
> directive
> > whose semantics are agreed with compilers to mean that an AVX2
> > vectorized version of the function is available (but other vectorized
> versions may not be).
> >
> > Obviously new functions go at new symbol versions (so GLIBC_2.21 at
> > present, not GLIBC_2.2.5 with a completely inappropriate Versions
> > comment in your patch).  I'd expect you to need appropriate section
> > directives for the data table you add to ensure it goes in read-only data, not
> writable.
> > And you shouldn't be adding a local PLT reference to cos; call an
> > internal hidden function.
> >
> 
> Cheers,
> Carlos.