This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: "Zamyatin, Igor" <igor dot zamyatin at intel dot com>, Jakub Jelinek <jakub at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 27 Nov 2014 20:12:44 +0000
- 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> <6D39441BF12EF246A7ABCE6654B0235320F09D65 at LEMAIL01 dot le dot imgtec dot org> <20140911210246 dot GN23797 at brightrain dot aerifal dot cx> <87a9655rnu dot fsf at tassilo dot jf dot intel dot com> <20140912074251 dot GZ17454 at tucnak dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1409121700030 dot 1118 at digraph dot polyomino dot org dot uk> <20140912170827 dot GE17454 at tucnak dot redhat dot com> <CAMXFM3u5DM_W=iiVReBszH4TY4Wwf3Vm7d79chwdfD_J5tTz5A at mail dot gmail dot com> <20141112175149 dot GK5026 at tucnak dot redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1411121809000 dot 23958 at digraph dot polyomino dot org dot uk> <0EFAB2BDD0F67E4FB6CCC8B9F87D756969C63403 at IRSMSX152 dot ger dot corp dot intel dot com> <alpine dot DEB dot 2 dot 10 dot 1411172353190 dot 3980 at digraph dot polyomino dot org dot uk> <CAMXFM3vYXM2xxqk3qCRE2z3ot8NQ=QLaAvVkdQXPPRneTCVUAA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1411271711550 dot 2940 at digraph dot polyomino dot org dot uk> <CAMXFM3vc0EXiR0bbC-n8S1+bW621xmev4LAQL2_8iiu5zPyTvA at mail dot gmail dot com>
On Thu, 27 Nov 2014, Andrew Senkevich wrote:
> 2014-11-27 20:17 GMT+03:00 Joseph Myers <email@example.com>:
> > This is all that is needed. It needs to be written in a
> > compiler-independent manner (and agreed between compilers), and state
> > explicitly that the semantics of those pragmas are independent of the
> > processor for which code is being generated (so, for example, those
> > pragmas must not be interpreted as meaning AVX512 versions of functions
> > are available even if code is being built for a processor with AVX512
> > support) and that any future ABI extension that defines additional vector
> > function versions will also define a different pragma to declare their
> > availability.
> GLIBC 2.21 VECTOR MATH FUNCTION NAME VARIANTS FOR x86_64
Should be something like: "OpenMP vector function ABI for x86_64" (as it's
about the meaning of #pragma omp declare simd for x86_64, and then glibc
is simply a user - any other library could equally rely on such an ABI to
describe the meaning of such a pragma in its headers).
> #pragma omp declare simd notinbranch simdlen(2) for some function
> âfuncâ means what the name of vector version is:
> _ZGVbN2v_func (it is SSE4 implementation).
> #pragma omp declare simd notinbranch simdlen(4) for some function
> âfuncâ means what the following names are available:
> _ZGVcN4v_func (it is AVX implementation)
> _ZGVdN4v_func (it is AVX2 implementation).
> Every vector function should be provided by Glibc for each supported
> ISA (currently SSE4, AVX and AVX2).
The generic statement would seem to mean: if simdlen(2) is used then only
the SSE4 version is needed; if simdlen(4) is used then the AVX and AVX2
versions are needed; only if both are used are all three versions then
needed. Is that accurate? This ABI document should be defining what any
library can rely on when providing SIMD function implementations and an
associated installed header that may be used with multiple compilers,
rather than talking specifically about glibc choices.
> Those pragmas must not be interpreted as meaning AVX512 versions of
> functions are available even if code is being built for a processor
> with AVX512 support.
This should say "for example" or similar (AVX512 is simply an illustrative
> Is it Ok and where is the proper place to put this document, include
> to documentation I think, not to wiki?
I suggest putting the OpenMP ABI for x86_64 alongside that other ABI
document you mentioned. Or, you could add all the relevant OpenMP
information to the x86_64 ABI document:
http://www.x86-64.org/svn/trunk/x86-64-ABI/ - discussed on the
firstname.lastname@example.org mailing list.
The important thing is not so much where it goes - it's that OpenMP
maintainers for relevant compilers (probably GCC, LLVM, Intel compiler)
agree that it represents how they intend to interpret the pragmas, so that
when glibc installs headers with those pragmas we can be confident
compilers will interpret them as intended and so programs can be built
with one compiler to use these functions in glibc built with another
Joseph S. Myers