From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Christoph Lauter <christoph.lauter@lip6.fr>
Cc: Andrew Senkevich <andrew.n.senkevich@gmail.com>,
Carlos O'Donell <carlos@redhat.com>,
libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [RFC] How to add vector math functions to Glibc
Date: Tue, 30 Sep 2014 20:15:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1409302003410.12188@digraph.polyomino.org.uk> (raw)
In-Reply-To: <542AF92E.8090708@lip6.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
next prev parent reply other threads:[~2014-09-30 20:15 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 13:48 Andrew Senkevich
2014-09-18 13:57 ` Andrew Senkevich
2014-09-18 17:05 ` Joseph S. Myers
2014-09-22 11:48 ` Andrew Senkevich
2014-09-22 12:37 ` Joseph S. Myers
2014-09-24 19:46 ` Andrew Senkevich
2014-09-24 20:19 ` Joseph S. Myers
2014-09-25 15:18 ` Andrew Senkevich
2014-09-25 15:40 ` H.J. Lu
2014-09-25 19:27 ` Carlos O'Donell
2014-09-25 19:37 ` H.J. Lu
2014-09-25 19:55 ` Carlos O'Donell
2014-09-25 20:03 ` H.J. Lu
2014-09-25 20:48 ` Carlos O'Donell
2014-09-26 13:46 ` Andrew Senkevich
2014-09-26 14:13 ` Carlos O'Donell
2014-09-26 14:15 ` Carlos O'Donell
2014-09-30 15:00 ` Andrew Senkevich
2014-09-30 15:44 ` Andreas Schwab
2014-09-30 15:53 ` Andrew Senkevich
2014-09-30 16:16 ` Andreas Schwab
2014-09-30 16:30 ` Andrew Senkevich
2014-09-30 16:35 ` Joseph S. Myers
2014-09-30 18:40 ` Christoph Lauter
2014-09-30 20:15 ` Joseph S. Myers [this message]
2014-10-02 11:55 ` Andrew Senkevich
2014-10-02 14:21 ` Joseph S. Myers
2014-10-09 17:10 ` Andrew Senkevich
2014-10-09 17:39 ` Andreas Schwab
2014-10-09 17:46 ` Joseph S. Myers
2014-10-09 17:45 ` Joseph S. Myers
2014-10-10 13:27 ` Andrew Senkevich
2014-10-10 15:23 ` Joseph S. Myers
2014-10-16 16:37 ` Andrew Senkevich
2014-10-16 21:51 ` Joseph S. Myers
2014-10-21 13:20 ` Andrew Senkevich
2014-10-21 15:29 ` Joseph S. Myers
2014-10-23 19:23 ` Andrew Senkevich
2014-10-23 21:37 ` Joseph S. Myers
2014-10-27 14:00 ` Andrew Senkevich
2014-10-27 14:39 ` Joseph S. Myers
2014-10-29 13:00 ` Andrew Senkevich
2014-10-29 18:50 ` Joseph S. Myers
2014-10-30 12:15 ` Andrew Senkevich
2014-10-30 13:55 ` Joseph S. Myers
2014-10-30 20:07 ` Joseph S. Myers
2014-10-31 10:24 ` Andrew Senkevich
2014-11-06 20:51 ` Andrew Senkevich
2014-11-14 15:45 ` Andrew Senkevich
2014-11-14 16:51 ` Joseph Myers
2014-11-18 19:06 ` Andrew Senkevich
2014-11-18 22:49 ` Joseph Myers
2014-09-30 18:40 ` Andrew Senkevich
2014-09-30 20:03 ` Joseph S. Myers
2014-10-01 13:26 ` Andrew Senkevich
2014-10-01 13:46 ` Joseph S. Myers
2014-10-01 18:47 ` Andrew Senkevich
2014-09-26 15:03 ` H.J. Lu
2014-09-26 15:48 ` Carlos O'Donell
2014-09-26 16:08 ` H.J. Lu
2014-09-26 17:55 ` Carlos O'Donell
2014-09-26 18:06 ` H.J. Lu
2014-09-30 16:17 ` Andrew Pinski
2014-09-18 15:37 ` H.J. Lu
2014-09-18 17:29 ` Andrew Senkevich
2014-09-21 16:31 ` Andi Kleen
2014-09-25 19:43 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1409302003410.12188@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=andrew.n.senkevich@gmail.com \
--cc=carlos@redhat.com \
--cc=christoph.lauter@lip6.fr \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).