Message ID | CAMXFM3tO7MTYCq8-YFZacdbLvR4iAab_n04AuB+rp2Phs4BvQg@mail.gmail.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 19217 invoked by alias); 24 Sep 2014 19:46:26 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 19207 invoked by uid 89); 24 Sep 2014 19:46:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f173.google.com X-Received: by 10.140.19.36 with SMTP id 33mr13088565qgg.32.1411587982087; Wed, 24 Sep 2014 12:46:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <Pine.LNX.4.64.1409181551370.31607@digraph.polyomino.org.uk> References: <CAMXFM3tjquzniXP1weqxSVFJyhXqsf2PHuyrrrmqp7K0ZzORqA@mail.gmail.com> <CAMXFM3sGMNX1DEPAMt7qUR4UREF_xUAQjCG1OjBiZH2aoOFiPA@mail.gmail.com> <Pine.LNX.4.64.1409181551370.31607@digraph.polyomino.org.uk> From: Andrew Senkevich <andrew.n.senkevich@gmail.com> Date: Wed, 24 Sep 2014 23:45:52 +0400 Message-ID: <CAMXFM3tO7MTYCq8-YFZacdbLvR4iAab_n04AuB+rp2Phs4BvQg@mail.gmail.com> Subject: Re: [RFC] How to add vector math functions to Glibc To: "Joseph S. Myers" <joseph@codesourcery.com> Cc: libc-alpha <libc-alpha@sourceware.org> Content-Type: text/plain; charset=UTF-8 |
Commit Message
Andrew Senkevich
Sept. 24, 2014, 7:45 p.m. UTC
Hi Joseph, >> > 1. Should functions go in libm or a separate libmvec library? >> >> If integrate new functions with libm it will be easier for developers >> to employ vectorization and should improve acceptance. >> Libmvec case affects compiler options and it seems new header need to >> be included instead of math.h, or is it OK include it in math.h? >> But libmvec could be better from the side of optional build (mentioned >> later in 2.) in case of addition most modern implementations. > > There is also the option of installing libm.so as a linker script that > refers to libmvec inside AS_NEEDED - libc.so is already a linker script > after all. That way, libmvec would automatically be linked into programs > that need it (preserving compatibility with the POSIX rules about what > library names need specifying to get what functions), without restricting > the tools that can build glibc if vector extensions are added for which > tool support is recent, but building libmvec is optional. is it OK to have following changes in GLIBC build: WBR, Andrew
Comments
On Wed, 24 Sep 2014, Andrew Senkevich wrote: > Hi Joseph, > > >> > 1. Should functions go in libm or a separate libmvec library? > >> > >> If integrate new functions with libm it will be easier for developers > >> to employ vectorization and should improve acceptance. > >> Libmvec case affects compiler options and it seems new header need to > >> be included instead of math.h, or is it OK include it in math.h? > >> But libmvec could be better from the side of optional build (mentioned > >> later in 2.) in case of addition most modern implementations. > > > > There is also the option of installing libm.so as a linker script that > > refers to libmvec inside AS_NEEDED - libc.so is already a linker script > > after all. That way, libmvec would automatically be linked into programs > > that need it (preserving compatibility with the POSIX rules about what > > library names need specifying to get what functions), without restricting > > the tools that can build glibc if vector extensions are added for which > > tool support is recent, but building libmvec is optional. > > is it OK to have following changes in GLIBC build: This patch doesn't seem to be relative to current sources. > diff --git a/Makerules b/Makerules > index 6b30e8c..058e748 100644 > --- a/Makerules > +++ b/Makerules > @@ -965,7 +965,22 @@ $(inst_libdir)/libc.so: $(common-objpfx)format.lds \ > ' AS_NEEDED (' $(rtlddir)/$(rtld-installed-name) ') )' \ > ) > $@.new > mv -f $@.new $@ > - > +else > +ifeq ($(subdir),mathvect) > +# We need to install libm.so as linker script > +# for more comfortable use of libmvect library. If consensus ends up being to have such a library (libmvec or libmvect?), then the installation rules for libm.so as a linker script should go in math/Makefile, not the toplevel Makerules. (I don't know what if any changes might be needed to allow subdirectories to provide libraries as linker scripts.) > diff --git a/shlib-versions b/shlib-versions > index 40469bd..8fddc04 100644 > --- a/shlib-versions > +++ b/shlib-versions > @@ -35,6 +35,12 @@ sh.*-.*-linux.* libm=6 GLIBC_2.2 > .*-.*-linux.* libm=6 > .*-.*-gnu-gnu.* libm=6 > > +# We provide libmvect.so.1 starting from GLIBC_2.21 symbol set. > +sparc64.*-.*-linux.* libmvect=1 GLIBC_2.21 > +sh.*-.*-linux.* libmvect=1 GLIBC_2.21 > +.*-.*-linux.* libmvect=1 GLIBC_2.21 > +.*-.*-gnu-gnu.* libmvect=1 GLIBC_2.21 No. No architecture-specific or OS-specific content goes in shlib-versions outside the appropriate sysdeps directories any more, and shlib-versions no longer has a first column listing patterns matching configuration triplets. Since the library will be architecture-specific, shlib-versions entries for its symbol versions would go in the relevant architecture files only when support is actually added for a given library. But actually you don't need such entries, since each architecture will have Versions file entries for the symbols provided in this library on that architecture; symbol versions in shlib-versions only serve to override Versions files. So all you need is a single toplevel shlib-versions line to specify the SONAME. That is, a line just saying libmvect=1 or similar. Also, some configuration support will be needed to allow an architecture to specify (via its sysdeps configure fragments, I suppose) whether it supports this library at all, so builds for other architectures don't attempt to build it. If not built, of course libm.so should remain as-is; it can't become a linker script referring to the new library.
> If consensus ends up being to have such a library (libmvec or libmvect?), > then the installation rules for libm.so as a linker script should go in > math/Makefile, not the toplevel Makerules. (I don't know what if any > changes might be needed to allow subdirectories to provide libraries as > linker scripts.) There were three options about the place where to add vectorized math functions: 1. GLIBC (libm) 2. GLIBC (additional library) 3. GCC In GLIBC cases build of vectorized functions can be conditional, no additional -lmvec required because of libm.so installed as linked script in case of vectorized functions available, so it seems not very important whether functions located in additional library or in libm. We have different feedback on that three options. But it is important to determine now for further implementation. How can we achieve the final decision?
On Thu, Sep 25, 2014 at 8:17 AM, Andrew Senkevich <andrew.n.senkevich@gmail.com> wrote: >> If consensus ends up being to have such a library (libmvec or libmvect?), >> then the installation rules for libm.so as a linker script should go in >> math/Makefile, not the toplevel Makerules. (I don't know what if any >> changes might be needed to allow subdirectories to provide libraries as >> linker scripts.) > > There were three options about the place where to add vectorized math functions: > > 1. GLIBC (libm) > 2. GLIBC (additional library) > 3. GCC > > In GLIBC cases build of vectorized functions can be conditional, no > additional -lmvec required because of libm.so installed as linked > script in case of vectorized functions available, so it seems not very > important whether functions located in additional library or in libm. > I don't think they should be in libm since most of applications won't use those vector functions, which increase libm size unnecessarily. A separate library is better.
On 09/25/2014 11:40 AM, H.J. Lu wrote: > On Thu, Sep 25, 2014 at 8:17 AM, Andrew Senkevich > <andrew.n.senkevich@gmail.com> wrote: >>> If consensus ends up being to have such a library (libmvec or libmvect?), >>> then the installation rules for libm.so as a linker script should go in >>> math/Makefile, not the toplevel Makerules. (I don't know what if any >>> changes might be needed to allow subdirectories to provide libraries as >>> linker scripts.) >> >> There were three options about the place where to add vectorized math functions: >> >> 1. GLIBC (libm) >> 2. GLIBC (additional library) >> 3. GCC >> >> In GLIBC cases build of vectorized functions can be conditional, no >> additional -lmvec required because of libm.so installed as linked >> script in case of vectorized functions available, so it seems not very >> important whether functions located in additional library or in libm. >> > > I don't think they should be in libm since most of applications > won't use those vector functions, which increase libm size > unnecessarily. A separate library is better. I agree. A distinct libmvec.so is best. I see the consensus that #2 is the way forward. Cheers, Carlos.
On Thu, Sep 25, 2014 at 12:27 PM, Carlos O'Donell <carlos@redhat.com> wrote: > On 09/25/2014 11:40 AM, H.J. Lu wrote: >> On Thu, Sep 25, 2014 at 8:17 AM, Andrew Senkevich >> <andrew.n.senkevich@gmail.com> wrote: >>>> If consensus ends up being to have such a library (libmvec or libmvect?), >>>> then the installation rules for libm.so as a linker script should go in >>>> math/Makefile, not the toplevel Makerules. (I don't know what if any >>>> changes might be needed to allow subdirectories to provide libraries as >>>> linker scripts.) >>> >>> There were three options about the place where to add vectorized math functions: >>> >>> 1. GLIBC (libm) >>> 2. GLIBC (additional library) >>> 3. GCC >>> >>> In GLIBC cases build of vectorized functions can be conditional, no >>> additional -lmvec required because of libm.so installed as linked >>> script in case of vectorized functions available, so it seems not very >>> important whether functions located in additional library or in libm. >>> >> >> I don't think they should be in libm since most of applications >> won't use those vector functions, which increase libm size >> unnecessarily. A separate library is better. > > I agree. A distinct libmvec.so is best. > > I see the consensus that #2 is the way forward. Since this vector library targets GCC, there are pros to put it in GCC.
On 09/25/2014 03:37 PM, H.J. Lu wrote: > On Thu, Sep 25, 2014 at 12:27 PM, Carlos O'Donell <carlos@redhat.com> wrote: >> On 09/25/2014 11:40 AM, H.J. Lu wrote: >>> On Thu, Sep 25, 2014 at 8:17 AM, Andrew Senkevich >>> <andrew.n.senkevich@gmail.com> wrote: >>>>> If consensus ends up being to have such a library (libmvec or libmvect?), >>>>> then the installation rules for libm.so as a linker script should go in >>>>> math/Makefile, not the toplevel Makerules. (I don't know what if any >>>>> changes might be needed to allow subdirectories to provide libraries as >>>>> linker scripts.) >>>> >>>> There were three options about the place where to add vectorized math functions: >>>> >>>> 1. GLIBC (libm) >>>> 2. GLIBC (additional library) >>>> 3. GCC >>>> >>>> In GLIBC cases build of vectorized functions can be conditional, no >>>> additional -lmvec required because of libm.so installed as linked >>>> script in case of vectorized functions available, so it seems not very >>>> important whether functions located in additional library or in libm. >>>> >>> >>> I don't think they should be in libm since most of applications >>> won't use those vector functions, which increase libm size >>> unnecessarily. A separate library is better. >> >> I agree. A distinct libmvec.so is best. >> >> I see the consensus that #2 is the way forward. > > Since this vector library targets GCC, there are > pros to put it in GCC. Sorry, I don't understand this part, and perhaps that's why I didn't understand question 7 in the previous post. What does it mean for the vector library to target GCC? Cheers, Carlos.
On Thu, Sep 25, 2014 at 12:55 PM, Carlos O'Donell <carlos@redhat.com> wrote: > On 09/25/2014 03:37 PM, H.J. Lu wrote: >> On Thu, Sep 25, 2014 at 12:27 PM, Carlos O'Donell <carlos@redhat.com> wrote: >>> On 09/25/2014 11:40 AM, H.J. Lu wrote: >>>> On Thu, Sep 25, 2014 at 8:17 AM, Andrew Senkevich >>>> <andrew.n.senkevich@gmail.com> wrote: >>>>>> If consensus ends up being to have such a library (libmvec or libmvect?), >>>>>> then the installation rules for libm.so as a linker script should go in >>>>>> math/Makefile, not the toplevel Makerules. (I don't know what if any >>>>>> changes might be needed to allow subdirectories to provide libraries as >>>>>> linker scripts.) >>>>> >>>>> There were three options about the place where to add vectorized math functions: >>>>> >>>>> 1. GLIBC (libm) >>>>> 2. GLIBC (additional library) >>>>> 3. GCC >>>>> >>>>> In GLIBC cases build of vectorized functions can be conditional, no >>>>> additional -lmvec required because of libm.so installed as linked >>>>> script in case of vectorized functions available, so it seems not very >>>>> important whether functions located in additional library or in libm. >>>>> >>>> >>>> I don't think they should be in libm since most of applications >>>> won't use those vector functions, which increase libm size >>>> unnecessarily. A separate library is better. >>> >>> I agree. A distinct libmvec.so is best. >>> >>> I see the consensus that #2 is the way forward. >> >> Since this vector library targets GCC, there are >> pros to put it in GCC. > > Sorry, I don't understand this part, and perhaps that's why I didn't > understand question 7 in the previous post. > > What does it mean for the vector library to target GCC? > From https://sourceware.org/glibc/wiki/libm#Addition_of_x86_64_vector_math_functions_to_Glibc 3.1. Goal Main goal is to improve vectorization of GCC with OpenMP4.0 SIMD constructs (#2.8 in http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf and Cilk Plus constructs (#6-8 in http://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm) on x86_64 by adding SSE4, AVX and AVX2 vector implementations of several vector math functions (float and double versions). AVX-512 versions are planned to be added later. These functions can be also used manually (with intrinsics) by developers to obtain speedup. So it is mainly for GCC.
On 09/25/2014 04:03 PM, H.J. Lu wrote: >> Sorry, I don't understand this part, and perhaps that's why I didn't >> understand question 7 in the previous post. >> >> What does it mean for the vector library to target GCC? >> > > From > > https://sourceware.org/glibc/wiki/libm#Addition_of_x86_64_vector_math_functions_to_Glibc Thanks for the pointer. I understand now. > 3.1. Goal > > Main goal is to improve vectorization of GCC with OpenMP4.0 SIMD > constructs (#2.8 in http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf > and Cilk Plus constructs (#6-8 in > http://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm) > on x86_64 by adding SSE4, AVX and AVX2 vector implementations of > several vector math functions (float and double versions). AVX-512 > versions are planned to be added later. These functions can be also > used manually (with intrinsics) by developers to obtain speedup. > > So it is mainly for GCC. The only counter-argument to that is that a single implementation in glibc can be shared by gcc and llvm or any other compiler. As noted in "3.5 Open questions, a." Intel needs to decide where they want this piece of technology to reside. I don't know that the community can make this choice for Intel. The community is ready to work with Intel to implement this in glibc. I've tried to clarify a few of these: https://sourceware.org/glibc/wiki/libm#Open_questions Cheers, Carlos.
>> 3.1. Goal >> >> Main goal is to improve vectorization of GCC with OpenMP4.0 SIMD >> constructs (#2.8 in http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf >> and Cilk Plus constructs (#6-8 in >> http://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm) >> on x86_64 by adding SSE4, AVX and AVX2 vector implementations of >> several vector math functions (float and double versions). AVX-512 >> versions are planned to be added later. These functions can be also >> used manually (with intrinsics) by developers to obtain speedup. >> >> So it is mainly for GCC. > > The only counter-argument to that is that a single implementation > in glibc can be shared by gcc and llvm or any other compiler. As > noted in "3.5 Open questions, a." Yes, it was a little bit inaccurate, corrected on wiki. > Intel needs to decide where they want this piece of technology > to reside. I don't know that the community can make this choice > for Intel. > > The community is ready to work with Intel to implement this in > glibc. Yes, we also would like to add vector functions to new library libmvec. So lets discuss Glibc build changes. Build of libmvec (and hence libm.so installation) need to be architecture dependent and optional, and some changes already was discussed in https://sourceware.org/ml/libc-alpha/2014-09/msg00578.html. Is it OK additionally to have configure option --enable-mathvec with default=no and with default=yes for x86_86 build? -- WBR, Andrew
On 09/26/2014 09:45 AM, Andrew Senkevich wrote: >>> 3.1. Goal >>> >>> Main goal is to improve vectorization of GCC with OpenMP4.0 SIMD >>> constructs (#2.8 in http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf >>> and Cilk Plus constructs (#6-8 in >>> http://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm) >>> on x86_64 by adding SSE4, AVX and AVX2 vector implementations of >>> several vector math functions (float and double versions). AVX-512 >>> versions are planned to be added later. These functions can be also >>> used manually (with intrinsics) by developers to obtain speedup. >>> >>> So it is mainly for GCC. >> >> The only counter-argument to that is that a single implementation >> in glibc can be shared by gcc and llvm or any other compiler. As >> noted in "3.5 Open questions, a." > > Yes, it was a little bit inaccurate, corrected on wiki. Thanks. Having the wiki document is useful to allow us and others to stay organized over the decisions we've already made. I've moved the two answered questions into a "Consensus" header for the vector library. Please correct this if I'm wrong. >> Intel needs to decide where they want this piece of technology >> to reside. I don't know that the community can make this choice >> for Intel. >> >> The community is ready to work with Intel to implement this in >> glibc. > > Yes, we also would like to add vector functions to new library libmvec. OK. Cheers, Carlos.
On 09/26/2014 09:45 AM, Andrew Senkevich wrote: > So lets discuss Glibc build changes. > Build of libmvec (and hence libm.so installation) need to be > architecture dependent and optional, and some changes already was > discussed in https://sourceware.org/ml/libc-alpha/2014-09/msg00578.html. > Is it OK additionally to have configure option --enable-mathvec with > default=no and with default=yes for x86_86 build? Under what circumstances would a non-x86_64 target build with --enable-mathvec? When they have their own API/ABI standard to implement and provide in libmvec.so? What's wrong with simply producing a libmvec.so that has no public symbols? It simplifies everything to just always ship libmvec.so, even if it's empty. Cheers, Carlos.
On Thu, Sep 25, 2014 at 1:48 PM, Carlos O'Donell <carlos@redhat.com> wrote: > On 09/25/2014 04:03 PM, H.J. Lu wrote: >>> Sorry, I don't understand this part, and perhaps that's why I didn't >>> understand question 7 in the previous post. >>> >>> What does it mean for the vector library to target GCC? >>> >> >> From >> >> https://sourceware.org/glibc/wiki/libm#Addition_of_x86_64_vector_math_functions_to_Glibc > > Thanks for the pointer. I understand now. > >> 3.1. Goal >> >> Main goal is to improve vectorization of GCC with OpenMP4.0 SIMD >> constructs (#2.8 in http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf >> and Cilk Plus constructs (#6-8 in >> http://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm) >> on x86_64 by adding SSE4, AVX and AVX2 vector implementations of >> several vector math functions (float and double versions). AVX-512 >> versions are planned to be added later. These functions can be also >> used manually (with intrinsics) by developers to obtain speedup. >> >> So it is mainly for GCC. > > The only counter-argument to that is that a single implementation > in glibc can be shared by gcc and llvm or any other compiler. As > noted in "3.5 Open questions, a." > I don't think it is an issue since llvm uses libraries from GCC by default and put it in GLIBC doesn't help llvm on non-GLIBC based systems either. Put it in GLIBC means that GCC 5.0 may not support vector math, depending on the build or target GLIBC. It is not a good GCC user experience. Put it in GCC means that GCC 5.0 supports vector math on all platforms supported by vector math, including non-GLIBC based systems. That is true that programmers who want to use vector math directly need to install GCC 5.0. That is one reason I am asking who is the main user of vector math.
On 09/26/2014 11:03 AM, H.J. Lu wrote: > Put it in GLIBC means that GCC 5.0 may not support vector > math, depending on the build or target GLIBC. It is not a good > GCC user experience. The same goes for all the other C11 and C++11 features we coordinate with glibc? I don't see how this has anything to do with a "user experience." The distribution maintainers need to make sure glibc is up to date, and gcc's required features are present. This is always how it works. > That is true that programmers who want to use vector math > directly need to install GCC 5.0. That is one reason I am > asking who is the main user of vector math. That's a serious upgrade for many users. While backporting libmvec.so is pretty simple, and allows the feature to be present for immediate use directly by a developer, and later to be used when they are ready to upgrade to gcc 5.0. I think this chioce may actually be larger than just Intel. For example IBM, and particularly their Power vector math functions were explained to me as being callable directly by developers. Thus Power might want libmvec.so in glibc? I still believe that developers will want to call these by hand if possible for code that is hand-optimized. That IMO calls out for this to be libmvec.so in glibc. Not to mention that gcc has no math testing infrastructure and glibc does. We can immediately put all of this test infrastructure to play for libmvec.so. Cheers, Carlos.
On Fri, Sep 26, 2014 at 8:48 AM, Carlos O'Donell <carlos@redhat.com> wrote: > On 09/26/2014 11:03 AM, H.J. Lu wrote: >> Put it in GLIBC means that GCC 5.0 may not support vector >> math, depending on the build or target GLIBC. It is not a good >> GCC user experience. > > The same goes for all the other C11 and C++11 features we > coordinate with glibc? I don't see how this has anything to do > with a "user experience." The distribution maintainers need to > make sure glibc is up to date, and gcc's required features are > present. This is always how it works. When there is no choice, then you don't have a choice. >> That is true that programmers who want to use vector math >> directly need to install GCC 5.0. That is one reason I am >> asking who is the main user of vector math. > > That's a serious upgrade for many users. I view it quite opposite. No one I know of installs a new GLIBC unless it comes from the system. But they may install a new GCC. It is much easier to install a new GCC than a new GLIBC. > While backporting libmvec.so is pretty simple, and allows > the feature to be present for immediate use directly by a > developer, and later to be used when they are ready to > upgrade to gcc 5.0. Same backport goes for GCC. > I think this chioce may actually be larger than just Intel. > > For example IBM, and particularly their Power vector math > functions were explained to me as being callable directly > by developers. Thus Power might want libmvec.so in glibc? Does Power have the same API as x86? If not, how will they be used by programmers? Again, we need to decide 1. Who is the main user. 2. How it is used by the main user. 3. What is the impact on the programmers. If we put it in GLIBC, we should have a API with a generic implementation and each target can have optimized implementation. > I still believe that developers will want to call these > by hand if possible for code that is hand-optimized. One can do that, regardless whether vector math is in GCC or GLIBC. > That IMO calls out for this to be libmvec.so in glibc. > > Not to mention that gcc has no math testing infrastructure > and glibc does. We can immediately put all of this test > infrastructure to play for libmvec.so. Vector math can have a testsuite, like other run-time libraries.
On 09/26/2014 12:08 PM, H.J. Lu wrote: >> I think this chioce may actually be larger than just Intel. >> >> For example IBM, and particularly their Power vector math >> functions were explained to me as being callable directly >> by developers. Thus Power might want libmvec.so in glibc? > > Does Power have the same API as x86? If not, how will they > be used by programmers? Power does not have the same API. I expect that David Edhelson was talking about these: http://pic.dhe.ibm.com/infocenter/compbg/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.bg.doc%2Fproguide%2Fvector.html Though I haven't verified. > Again, we need to decide > > 1. Who is the main user. Normal developers. > 2. How it is used by the main user. They call those functions. > 3. What is the impact on the programmers. If the functions are in glibc, we can deploy them independent of compiler. > If we put it in GLIBC, we should have a API with a generic > implementation and each target can have optimized implementation. I disagree. Each target will likely have two APIs: (a) The legacy API supported for compatibility with existing applications following the existing published APIs. e.g. IBM and Intel vector functions. (b) A generic GNU implemetnation that all targets can have. We aren't even talking about (b) yet. Cheers, Carlos.
On Fri, Sep 26, 2014 at 10:55 AM, Carlos O'Donell <carlos@redhat.com> wrote: > On 09/26/2014 12:08 PM, H.J. Lu wrote: >>> I think this chioce may actually be larger than just Intel. >>> >>> For example IBM, and particularly their Power vector math >>> functions were explained to me as being callable directly >>> by developers. Thus Power might want libmvec.so in glibc? >> >> Does Power have the same API as x86? If not, how will they >> be used by programmers? > > Power does not have the same API. > > I expect that David Edhelson was talking about these: > http://pic.dhe.ibm.com/infocenter/compbg/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.bg.doc%2Fproguide%2Fvector.html > > Though I haven't verified. > >> Again, we need to decide >> >> 1. Who is the main user. > > Normal developers. > This isn't the same as the goal list at https://sourceware.org/glibc/wiki/libm#Addition_of_x86_64_vector_math_functions_to_Glibc which says: 3.1. Goal Main goal is utilize of SIMD constructs in OpenMP4.0 (#2.8 in http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf and Cilk Plus (#6-8 in http://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm) on x86_64 by adding vector implementations of several vector math functions (float and double versions). which is pretty much targeting compiler.
On Fri, Sep 26, 2014 at 10:55 AM, Carlos O'Donell <carlos@redhat.com> wrote: > On 09/26/2014 12:08 PM, H.J. Lu wrote: >>> I think this chioce may actually be larger than just Intel. >>> >>> For example IBM, and particularly their Power vector math >>> functions were explained to me as being callable directly >>> by developers. Thus Power might want libmvec.so in glibc? >> >> Does Power have the same API as x86? If not, how will they >> be used by programmers? > > Power does not have the same API. They do have a similar API; at least the Cell does: https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/6BFB9899CEA5456800257360001938B3/$file/SIMD_Library_Specification_for_CBEA_1.2.pdf (I Helped write this spec when I was at Sony). Which looks like it is also at http://pic.dhe.ibm.com/infocenter/compbg/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.bg.doc%2Fproguide%2Fmass_simd.html . Thanks, Andrew Pinski > > I expect that David Edhelson was talking about these: > http://pic.dhe.ibm.com/infocenter/compbg/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.bg.doc%2Fproguide%2Fvector.html > > Though I haven't verified. > >> Again, we need to decide >> >> 1. Who is the main user. > > Normal developers. > >> 2. How it is used by the main user. > > They call those functions. > >> 3. What is the impact on the programmers. > > If the functions are in glibc, we can deploy them independent > of compiler. > >> If we put it in GLIBC, we should have a API with a generic >> implementation and each target can have optimized implementation. > > I disagree. > > Each target will likely have two APIs: > > (a) The legacy API supported for compatibility with existing > applications following the existing published APIs. > e.g. IBM and Intel vector functions. > > (b) A generic GNU implemetnation that all targets can have. > > We aren't even talking about (b) yet. > > Cheers, > Carlos. >
diff --git a/Makeconfig b/Makeconfig index cef0f06..5173414 100644 --- a/Makeconfig +++ b/Makeconfig @@ -1060,11 +1060,11 @@ endif # These are the subdirectories containing the library source. The order # is more or less arbitrary. The sorting step will take care of the # dependencies. -all-subdirs = csu assert ctype locale intl catgets math setjmp signal \ - stdlib stdio-common libio malloc string wcsmbs time dirent \ - grp pwd posix io termios resource misc socket sysvipc gmon \ - gnulib iconv iconvdata wctype manual shadow gshadow po argp \ - crypt localedata timezone rt conform debug \ +all-subdirs = csu assert ctype locale intl catgets math mathvect setjmp \ + signal stdlib stdio-common libio malloc string wcsmbs time \ + dirent grp pwd posix io termios resource misc socket sysvipc \ + gmon gnulib iconv iconvdata wctype manual shadow gshadow po \ + argp crypt localedata timezone rt conform debug \ $(add-on-subdirs) dlfcn elf ifndef avoid-generated diff --git a/Makerules b/Makerules index 6b30e8c..058e748 100644 --- a/Makerules +++ b/Makerules @@ -965,7 +965,22 @@ $(inst_libdir)/libc.so: $(common-objpfx)format.lds \ ' AS_NEEDED (' $(rtlddir)/$(rtld-installed-name) ') )' \ ) > $@.new mv -f $@.new $@ - +else +ifeq ($(subdir),mathvect) +# We need to install libm.so as linker script +# for more comfortable use of libmvect library. +subdir_install: $(inst_libdir)/libm.so +$(inst_libdir)/libm.so: $(common-objpfx)format.lds \ + $(common-objpfx)math/libm.so$(libm.so-version) \ + $(common-objpfx)mathvect/libmvect.so$(libmvect.so-version) \ + $(+force) + (echo '/* GNU ld script */';\ + cat $<; \ + echo 'GROUP ( $(slibdir)/libm.so$(libm.so-version) ' \ + 'AS_NEEDED ( $(slibdir)/libmvect.so$(libmvect.so-version) ) )' \ + ) > $@.new + mv -f $@.new $@ +endif endif else diff --git a/shlib-versions b/shlib-versions index 40469bd..8fddc04 100644 --- a/shlib-versions +++ b/shlib-versions @@ -35,6 +35,12 @@ sh.*-.*-linux.* libm=6 GLIBC_2.2 .*-.*-linux.* libm=6 .*-.*-gnu-gnu.* libm=6 +# We provide libmvect.so.1 starting from GLIBC_2.21 symbol set. +sparc64.*-.*-linux.* libmvect=1 GLIBC_2.21 +sh.*-.*-linux.* libmvect=1 GLIBC_2.21 +.*-.*-linux.* libmvect=1 GLIBC_2.21 +.*-.*-gnu-gnu.* libmvect=1 GLIBC_2.21 + # We provide libc.so.6 for Linux kernel versions 2.0 and later. sh.*-.*-linux.* libc=6 GLIBC_2.2 sparc64.*-.*-linux.* libc=6 GLIBC_2.2 diff --git a/sysdeps/x86_64/fpu/Makefile b/sysdeps/x86_64/fpu/Makefile index 1cb3ec5..520ed09 100644 --- a/sysdeps/x86_64/fpu/Makefile +++ b/sysdeps/x86_64/fpu/Makefile @@ -1,3 +1,3 @@ -ifeq ($(subdir),math) -libm-support += svml_d_cos4_core svml_d_cos_data +ifeq ($(subdir),mathvect) +libmvect-support += svml_d_cos4_core svml_d_cos_data endif diff --git a/sysdeps/x86_64/fpu/Versions b/sysdeps/x86_64/fpu/Versions index 1717a7a..1fd0921 100644 --- a/sysdeps/x86_64/fpu/Versions +++ b/sysdeps/x86_64/fpu/Versions @@ -1,4 +1,4 @@ -libm { +libmvect { diff --git a/sysdeps/x86_64/fpu/svml_d_cos4_core.S b/sysdeps/x86_64/fpu/svml_d_cos4_core.S index 8334875..d7fd42f 100644 --- a/sysdeps/x86_64/fpu/svml_d_cos4_core.S +++ b/sysdeps/x86_64/fpu/svml_d_cos4_core.S @@ -167,7 +168,7 @@ _LBL_1_10: vmovsd 328(%rsp,%r15), %xmm0 vzeroupper - call __cos@PLT + call cos@PLT vmovsd %xmm0, 392(%rsp,%r15) jmp _LBL_1_8 @@ -178,8 +179,9 @@ _LBL_1_12: vmovsd 320(%rsp,%r15), %xmm0 vzeroupper - call __cos@PLT + call cos@PLT vmovsd %xmm0, 384(%rsp,%r15) jmp _LBL_1_7