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: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "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 18:00:38 +0200
- 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>
On Fri, 2014-09-12 at 11:10 -0400, Carlos O'Donell 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.
>From a long-term maintenance perspective, it seems easier to support
higher-level SIMD / vectorization abstractions in programming languages
than glibc APIs for each and every HW vector instruction variant. We'd
have an ABI to maintain too if we chose the runtime library route, but
then at least it's not another glibc API.