[Parallel_libs-commits] [PATCH] D24951: Import/adapt the SLEEF vector math-function library as an LLVM runtime

Francesco Petrogalli via Parallel_libs-commits parallel_libs-commits at lists.llvm.org
Wed Oct 12 04:55:41 PDT 2016


fpetrogalli added a comment.

In https://reviews.llvm.org/D24951#564785, @hfinkel wrote:

> The library name has been updated to be vmath. The function names now all look like:
>
>   __llvm_<func>_<type>[_<abi>]
>   
>
> So, for example, for sin the library contains on my x86_64 system:
>
>   __llvm_sin_f64
>   __llvm_sin_u1_f64
>   __llvm_sin_f32
>   __llvm_sin_u1_f32
>   __llvm_sin_u1_v2f64_sse2
>   __llvm_sin_v2f64_sse2
>   __llvm_sin_u1_v4f32_sse2
>   __llvm_sin_v4f32_sse2
>   __llvm_sin_u1_v4f64_avx
>   __llvm_sin_v4f64_avx
>   __llvm_sin_u1_v8f32_avx
>   __llvm_sin_v8f32_avx
>   __llvm_sin_u1_v4f64_avx2
>   __llvm_sin_v4f64_avx2
>   __llvm_sin_u1_v8f32_avx2
>   __llvm_sin_v8f32_avx2


i Hal,

thank you for working on including SLEEF into parallel-libs.

I think it would be great if the symbols provided by the "libvmath"
would be easily accessible also by other compilers.

The best way to achieve this is to make sure that the symbols names
are generated according a well known and accepted classification. I
think that generating the names under the "#pragma omp declare simd"
classification is the best way to achieve this, as the pragma takes
care of different aspects that need to be considered when generating a
vector version of a vector function.

To my understanding, this is what the Intel vector ABI [1] is taking
care of.

Since other compilers are interested in linking their vector code
again this library, I recommend using for each target architecture the
naming conventions specified in the Vector ABI - obviously, ARM may
develop such an equivalent ABI in the future.

For the end user interested in using the auto-vectorization framework
provided by their favourite compiler, using either "vector math
library - flavour A" (say sleef in parallel-libs) or another "vector
math library - flavour B" (say e.g. libmvec in glib) would reduce in
linking against one of the libraries. The auto-vectorizer would
be library independent (up to the need of knowing what vector math
functions are available in the code).

Does this make sense to you? Anyone else having arguments pro/against
this choice?

Regards,

Francesco

[1] https://sourceware.org/glibc/wiki/libmvec?action=AttachFile&do=view&target=VectorABI.txt


https://reviews.llvm.org/D24951





More information about the Parallel_libs-commits mailing list