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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, "Zamyatin, Igor" <igor dot zamyatin at intel dot com>, "Melik-Adamyan, Areg" <areg dot melik-adamyan at intel dot com>
- Date: Wed, 17 Sep 2014 12:34:43 +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> <5411F8D3 dot 7050001 at redhat dot com> <CAMXFM3vEbTO1ntx7KOAG21axosPApTG6vwpcnu7B4VVATD+USw at mail dot gmail dot com> <CAMe9rOqFmwMWYBSsg9gPNeB_nskWZMSpzeWwc=YomsTNzjCn1A at mail dot gmail dot com> <CAMXFM3uNrRrAHDdS0LnbRZ7QwEFv1yd25cu1Ht2NC8fMBxLsBA at mail dot gmail dot com> <20140917100849 dot GD17454 at tucnak dot redhat dot com> <CAMXFM3uBVX+V68-9zSgkV22rZ+MkYQvUQe6wjAKg9q2-cFhx=Q at mail dot gmail dot com>
On Wed, 17 Sep 2014, Andrew Senkevich wrote:
> thank you, this place will look so:
>
> #if defined (__x86_64__) && !defined _Mfloat_ && !defined _Mlong_double_ \
> && defined _OPENMP && _OPENMP >= 201307
> # define __DECL_SIMD _Pragma ("omp declare simd notinbranch")
> #else
> # define __DECL_SIMD
> #endif
No, we never put architecture conditionals like that in
architecture-independent headers. You have to use bits/*.h headers
(per-architecture) instead to provide all the information about which
functions have which vectorized versions. See what I suggested in
<https://sourceware.org/ml/libc-alpha/2014-09/msg00182.html> about macros
such as __DECL_SIMD_COS_DOUBLE.
There's no point in sending more patch revisions until there's consensus
on the overall implementation approach. Please go back several steps and
start an architecture-independent discussion in a new
architecture-independent thread seeking consensus on all the points I
raised in <https://sourceware.org/ml/libc-alpha/2014-09/msg00182.html>.
State your initial answers to these points so people can agree or disagree
with them, but be prepared to change following the results of the
discussion. Only once there is such consensus, write up the results on
the wiki, seek confirmation on the list that other people agree that what
you wrote up is an accurate representation of the consensus, and only then
start sending patches (which will probably put functions in libmvec, not
libm, based on the discussions so far). The patches have to follow the
consensus, not your preference if the consensus goes against what you
prefer.
<https://sourceware.org/glibc/wiki/libm> does not in any way reflect any
sort of consensus. It's *ideas and proposals*. Consensus can only be
reached after discussions on libc-alpha (and if no-one comments on
something, that's not consensus). In general, proposals are best posted
to libc-alpha so it's easy to tell what was being discussed in a
particular thread - proposals on wiki pages make it harder to follow the
discussion, as you need to work out which version of the wiki page someone
was referring to.
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?
--
Joseph S. Myers
joseph@codesourcery.com