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: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, "Zamyatin, Igor" <igor dot zamyatin at intel 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: Fri, 12 Sep 2014 12:31:36 -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> <CAMe9rOqXPoORKoqWXYCSBbpuketbQf-enBk60xPq5O_yOo+i5A at mail dot gmail dot com> <541239E7 dot 8070806 at redhat dot com> <CAMe9rOpbWjvOZpJzypn8FA3USu4XyTY=MTvOn+0eQt5fb0Fq_Q at mail dot gmail dot com> <54130CC8 dot 7060106 at redhat dot com> <CAMe9rOo3jhtdmQ8pRDXny_SA4k8yqSXTGmaM6d=eWNkVOzpCHQ at mail dot gmail dot com> <541345E6 dot 2010203 at redhat dot com>
On Fri, Sep 12, 2014 at 12:13 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/12/2014 03:05 PM, H.J. Lu wrote:
>> On Fri, Sep 12, 2014 at 8:10 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 09/12/2014 11:01 AM, H.J. Lu wrote:
>>>> On Thu, Sep 11, 2014 at 5:10 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>> On 09/11/2014 04:57 PM, H.J. Lu wrote:
>>>>>>> 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?
>>>>>
>>>>> That's certainly a discussion we can have.
>>>>>
>>>>> What do you see as the pros and cons?
>>>>>
>>>>
>>>> It depends on who are the main target users of this library.
>>>> If it is mainly for programmers to use them directly in their
>>>> applications, mostly independent of compilers, it should be
>>>> in glibc. But if it is mainly used by GCC, it should be in
>>>> GCC, just like other run-time libraries.
>>>
>>> The former. I want users to be able to call these functions
>>> directly regardless of the compiler. The same goes for the
>>> ppc-related API that has been in use for a long time by
>>> developers there.
>>>
>>> The compiler can certainly make use of these functions, and
>>> any more standard cross-machine GNU API we design, but it
>>> should always be possible to call them directly.
>>>
>>> Does this mean libmvec should be in glibc?
>>>
>>
>> If the target users are programmers, we should make it easier
>> to use for programmers. We can provide a generic API with a
>> generic implementation. Each target can provide an optimized
>> version which is transparent to users. We can use IFUNC to
>> select the best version at run-time.
>
> I think such an implementation is orthogonal to exposing the
> already documented vector functions supported by Intel?
>
> Similarly for IBM.
>
> First a foremost we should support users who are expecting
> to be able to call the functions Intel and IBM have already
> documented.
>
> Second to that we can create a new API?
>
> Note that the generic API might by very difficult to design,
> which is why I don't suggest we tackle it first.
>
I think it is the best solution for our users.
--
H.J.