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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "Zamyatin, Igor" <igor dot zamyatin at intel dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, "Melik-Adamyan, Areg" <areg dot melik-adamyan at intel dot com>, "jakub at redhat dot com" <jakub at redhat dot com>
- Date: Thu, 11 Sep 2014 13:57:31 -0700
- 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> <0EFAB2BDD0F67E4FB6CCC8B9F87D756969B4D6D8 at IRSMSX101 dot ger dot corp dot intel dot com> <Pine dot LNX dot 4 dot 64 dot 1409112047460 dot 5583 at digraph dot polyomino dot org dot uk>
On Thu, Sep 11, 2014 at 1:52 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Thu, 11 Sep 2014, Zamyatin, Igor wrote:
>
>> > > * 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.
>
> That doesn't answer my question. Maybe glibc 2.21 provides such versions
> for all x86 ISAs there are at present, up to AVX512 - and then a new
> extension AVX1024 appears. When GCC 7 is used with glibc 2.21 headers and
> -mavx1024, it must not try to generate calls to the AVX1024 functions,
> because glibc 2.21 doesn't have such functions. But maybe glibc 2.26 adds
> the AVX1024 functions. So something needs to be different in the headers
> of 2.26 to inform GCC 7 that AVX1024 versions of the functions are
> available. And I think that means the directive that communicates
> function availability to the compiler needs to identify the set of ISAs
> for which versions of the function in question are available.
>
Wouldn't it be better to put libmvec in GCC instead?
--
H.J.