This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>, Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, igor dot zamyatin at intel dot com, "Melik-Adamyan, Areg" <areg dot melik-adamyan at intel dot com>, jakub at redhat dot com
- Date: Thu, 11 Sep 2014 15:32:35 -0400
- Subject: Re: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3t=ppndDUBzHzSus7xyuF5hTaLFZ5b273jD39NtddSvsw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409101549490 dot 12853 at digraph dot polyomino dot org dot uk>
On 09/10/2014 12:07 PM, Joseph S. Myers wrote:
> On Wed, 10 Sep 2014, Andrew Senkevich wrote:
>
>> Hi all,
>>
>> this is the first patch in the series of patches which will add Intel
>> vectorized math functions to Glibc.
>
> 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.
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
> 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.
> * 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?
> * 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.
> * 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).
>
> * 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.