[RFC] How to add vector math functions to Glibc

  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
  

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.
>