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