This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] How to add vector math functions to Glibc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Christoph Lauter <christoph dot lauter at lip6 dot fr>
- Cc: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 30 Sep 2014 20:15:31 +0000
- Subject: Re: [RFC] How to add vector math functions to Glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3tjquzniXP1weqxSVFJyhXqsf2PHuyrrrmqp7K0ZzORqA at mail dot gmail dot com> <CAMXFM3sGMNX1DEPAMt7qUR4UREF_xUAQjCG1OjBiZH2aoOFiPA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409181551370 dot 31607 at digraph dot polyomino dot org dot uk> <CAMXFM3tO7MTYCq8-YFZacdbLvR4iAab_n04AuB+rp2Phs4BvQg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409242011260 dot 7597 at digraph dot polyomino dot org dot uk> <CAMXFM3tqiqUNuSU2KXvAFM-QescX3+6xUO9=z5X0Ac6C9qJ7zg at mail dot gmail dot com> <CAMe9rOq7bZHb8R=opUzSmAMGWjLpX21mR=Sx96cuBph=TTtDXA at mail dot gmail dot com> <54246CB5 dot 7020908 at redhat dot com> <CAMe9rOoLmJ2jHWmERoB0M83WNKovJOgh0--Kquw9O86A1tPU0g at mail dot gmail dot com> <5424733D dot 6010305 at redhat dot com> <CAMe9rOpacze055qyBFzz3M-b-GNtXCqZzMmkScBL9a94zVj28g at mail dot gmail dot com> <54247FAB dot 6050002 at redhat dot com> <CAMXFM3v8narOLMHC5U=fvyTFWV6s4ZACN-UrAC4fAcUs9SOFfA at mail dot gmail dot com> <54257507 dot 9070508 at redhat dot com> <CAMXFM3vOLspQtHxgJfD_Emht480w2RMbiwnEH6A_LhoS-JZFag at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409301620020 dot 15186 at digraph dot polyomino dot org dot uk> <542AF92E dot 8090708 at lip6 dot fr>
On Tue, 30 Sep 2014, Christoph Lauter wrote:
> Hi all,
>
> just 2cts from someone who wrote a couple of libm functions alreday in his
> life:
>
> Joseph S. Myers wrote on 30/09/2014 18:35:
>
> > > +# if defined _OPENMP && _OPENMP >= 201307
> > > +/* OpenMP case. */
> > > +# undef __DECL_SIMD_AVX2
> > > +# undef __DECL_SIMD_SSE4
> > > +# define __DECL_SIMD_AVX2 _Pragma("omp declare simd notinbranch")
> > > +# define __DECL_SIMD_SSE4 _Pragma("omp declare simd notinbranch")
> >
> > I think there should be a comment pointing to the ABI/API documentation
> > that says what function versions this pragma defines to be available and
> > guaranteeing that it will not be redefined to e.g. say that AVX512 is
> > available so that existing headers will work with future compilers (but
> > another pragma will be needed if in future AVX512 versions are added).
> >
>
> Yeah, the ABI/API is not quite self-documenting with functions declared as
> follows:
What I'm referring to here is somewhat different - it's the ABI/API that
defines the contact between the library and compiler implied by the pragma
(or, in the Cilk Plus case, by the attribute).
That ABI/API will effectively say "this pragma / attribute means that
versions of this function are available for the following vector ISAs"
(and then go on to say what the ABI is for each ISA). It should also say
explicitly that compilers must not interpret the pragma / attribute as
meaning that functions are available for any other vector ISAs and that
new pragmas / attributes will be defined for any new vector ISAs as
needed. That avoids future compilers misinterpreting glibc 2.21's headers
as meaning it provides e.g. AVX512 versions of functions.
This ABI/API should be generically about OpenMP / Cilk Plus on x86_64
processors, rather than specifically about GCC, to establish an
interpretation intended to be shared by any compiler that implements those
features, now or in the future.
(Of course then the patch does actually need to provide all the function
versions implied by the pragma / attribute.)
> > > + .align 64
> > > + .globl __gnu_svml_dcos_data
> > > +__gnu_svml_dcos_data:
> > > + .long 4294967295
> >
> > What are the semantics of the values in this table (please add a comment)?
> > How was this table generated?
> >
>
> Yeah, who codes floating-point values as (little-endian ?) memory notation in
> decimal? I would understand hexadecimal but decimal?
>
> As is, the code is unmaintainable.
And, generally, we want to be able to regenerate any such tables if there
are changes to the algorithms. This means at a minimum having comments
giving the semantics of the table (coefficients of whatever polynomial
approximation to a given function on given intervals, for example), but
preferably source code to generate the table.
--
Joseph S. Myers
joseph@codesourcery.com