[llvm-dev] [RFC][VECLIB] how should we legalize VECLIB calls?

Previous Topic Next Topic
classic Classic list List threaded Threaded
21 messages Options
Reply | Threaded
Open this post in threaded view

Re: [llvm-dev] [RFC][VECLIB] how should we legalize VECLIB calls?

Zhizhou Yang via llvm-dev


I am the main author of SLEEF( https://sleef.org ).

For resolution and mapping of vectorized math functions, an easy way
would be to allow users to choose a mapping through declaration of
vector math function prototype. It would be nice if we could make a new
function attribute for this. Then, the compiler does not need to care
about accuracy, domain, ant other things. Users can choose faster
functions regardless of fast-math options.

The header file would look like :

__attribute__((map_vectormathfunc("sin"))) __m128d Sleef_sind2_u35(__m128d);
__attribute__((map_vectormathfunc("sin"))) __m256d Sleef_sind4_u35(__m256d);
__attribute__((map_vectormathfunc("sin"))) __m128d Sleef_sind2_u10(__m128d);
__attribute__((map_vectormathfunc("sin"))) __m256d Sleef_sind4_u10(__m256d);

If usage of GNU vector ABI is preferred, it would be :

#pragma omp declare simd simdlen(2) notinbranch
__attribute__((map_vectormathfunc("sin"))) double Sleef_sin_u35(double);


Naoki Shibata

On 7/4/2018 4:47 PM, Simon Moll via llvm-dev wrote:

> Instead there is a lazy interface (PlatformInfo::getResolver) that takes
> in the scalar function name, the argument shapes and whether there is a
> non-uniform predicate at the call site. We currently return just one
> possible mapping per query but you could also generate a list of
> possible mappings and let the vectorizer decide for itself, from this
> tailored list, which mapping to use.
> This approach will scale not just to math functions.
> Behind the curtains, a call to ::getResolver works through a chain of
> ResolverServices that can raise their hand if they could provide a
> vector implementation for the scalar function.
> The first in the chain will check whether this is a math function and if
> it should use a VECLIB call (RV does this for SLEEF, the vectorized
> functions are actually linked in immediately). Since we are not tied to
> a static VECLIB table, we actually allow users to provide an ULP error
> bound on the math functions. The SLEEF resolver will only consider
> functions that are within that bound
> (https://github.com/cdl-saarland/rv/blob/develop/include/rv/sleefLibrary.h).
> Further down the chain, you have a resolver that checks whether the
> scalar callee is defined in the module and if so, whether it can invoke
> whole-function vectorization recursively on the callee (again, given the
> precise argument shapes, we will get a precise return value shape). Atm,
> we only do this to vectorize and inline scalar SLEEF functions but it is
> trivial to do that on the same module.

LLVM Developers mailing list
[hidden email]