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

[Naoki Shibata via llvm-dev]

Hello,

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 :

#ifdef SLEEF_LOWER_ACCURACY
__attribute__((map_vectormathfunc("sin"))) __m128d Sleef_sind2_u35(__m128d);
__attribute__((map_vectormathfunc("sin"))) __m256d Sleef_sind4_u35(__m256d);
#else
__attribute__((map_vectormathfunc("sin"))) __m128d Sleef_sind2_u10(__m128d);
__attribute__((map_vectormathfunc("sin"))) __m256d Sleef_sind4_u10(__m256d);
#endif


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);


Regards,

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.