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: Rich Felker <dalias at libc dot org>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, "igor dot zamyatin at intel dot com" <igor dot zamyatin at intel dot com>, "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 17:02:46 -0400
- 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>
On Thu, Sep 11, 2014 at 10:11:14AM +0000, Matthew Fortune wrote:
> Joseph S. Myers <joseph@codesourcery.com> writes:
> > On Wed, 10 Sep 2014, Andrew Senkevich wrote:
> >
> > > Hi all,
> > >
> > > this is the first patch in the series of patches which will add Intel
> > > vectorized math functions to Glibc.
> >
> > Please start by raising general design questions on libc-alpha before
> > sending any patches; only send patches once there is consensus on the
> > general questions and that consensus has been written up on a wiki page.
> > For example:
>
> FWIW I had envisaged vectorised math functions looking more generic such
> that they were not dependent on vector size:
>
> void sin_simd (float* dst, float* src, int count)
> {
> while (count > 0)
> {
> *dst = sinf (*src);
> dst++;
> src++;
> count--;
> }
> }
>
> With this pattern, the precise SIMD ISA extension is not important to the
> caller. The additional cost of loading/storing the data compared with the
> number of instructions required to perform the vectorised operation does
> not seem significant. Ifunc is then the obvious way to select the widest
> SIMD available at runtime.
This really seems like something the compiler should be doing --
translating parallelizable calls to the standard math functions into
calls to special simd versions (or better yet, LTO'ing in an
on-the-fly simd version based on the non-simd-specific code in libm.a)
rather than having applications written to a klunky API that's
designed around particular hardware features.
Rich