[llvm-dev] [cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.

[Francesco Petrogalli via llvm-dev]

+CC Alexey B.

> On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at cern.ch> wrote:
> 
> On Mon, 3 Jun 2019 at 20:00, Francesco Petrogalli via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> Hi All,
> 
> The original intend of this thread is to "Expose user provided vector function for auto-vectorization.”
> 
> I originally proposed to use OpenMP `declare variant` for the sake of using something that is defined by a standard. The RFC itself is not about fully implementing the `declare variant` directive. In fact, given the amount of complication it is bringing, I would like to move the discussion away from `declare variant`. Therefore, I kindly ask to move any further discussion about `declare variant` to a separate thread.
> 
> I believe that to "Expose user provided vector function for auto-vectorization” we need three components.
> 
> 1. The main component is the IR representation we want to give to this information. My proposal is to use the `vector-variant` attribute with custom symbol redirection. 
> 
>         vector-variant = {“_ZGVnN2v_f(custon_vector_f_2), _ZGVnN4v_f(custon_vector_f_4)”}
> 
> The names here are made of the Vector Function ABI mangled name, plus custom symbol redirection in parenthesis. I believe that themes mangled according to the Vector Function ABI have all the information needed to build the signature of the vector function and the properties of its parameters (linear, uniform, aligned…). This format will cover most (if not all) the cases that are needed for auto-vectorization. I am not aware of any situation in which this information might not be sufficient. Please provide such an example if you know of any.
> 
> We can attach the IR attribute to call instructions (preferred for avoiding conflicts when merging modules who don’t see the same attributes) or to function declaration, or both.
> 
> 2. The second component is a tool that other parts of LLVM (for example, the loop vectorizer) can use to query the availability of the vector function, the SVFS I have described in the original post of the RFC, which is based on interpreting the `vector-variant` attribute.
> 
> The final component is the one that seems to have generated most of the controversies discussed in the thread, and for which I decided to move away from `declare variant`.
> 
> 3. The third component is a set of descriptors that can be attached to the scalar function declaration / definition in the C/C++ source file, to be able to inform about the availability of an associated vector functions that can be used when / if needed.
> 
> As someone as suggested, we should use a custom attribute. Because the mangling scheme of the Vector Function ABI provides all the information about the shape and properties of the vector function, I propose the approach exemplified in the following code:
> 
> 
> ```
> // AArch64 Advanced SIMD compilation
> double foo(double) __attribute__(simd_variant(“nN2v”,”neon_foo”));
> float64x2_t neon_foo(float64x2_t x) {…}
> 
> // x86 SSE compilation
> double foo(double) __attribute__(simd_variant(“aN2v”,”sse_foo”));
> __m128 sse_foo(__m128 x) {…}
> ```
> 
> The attribute would use the “core” tokens of the mangled names (without _ZGV prefix and the scalar function name postfix) to describe the vector function provided in the redirection.
> 
> Formal syntax:
> 
> ```
> __attribute__(simd_variant(“<isa><mask><VLEN><par_type_list>”, “custom_vector_name”))
> 
> <isa> := “a” (SSE), “b” (AVX) , …, “n” (NEON), “s” (SVE) (from the vector function ABI specifications of each of the targets that support this, for now AArch64 and x86)
> 
> <mask> := “N” for no mask, or “M” for masking
> 
> <VLEN> := number of lanes in a vector | “x” for scalable vectorization (defined in the AArch64 Vector function ABI).
> 
> <part_type_list> := “v” | “l” | … all these tokens are defined in the Vector Function ABI of the target (which get selected by the <isa>). FWIW, they are the same for x86 and AArch64.
> ```
> 
> Please let me know what you thing about this proposal. I will rework the proposal if it makes it easier to follow and submit a new RFC about it, but before getting into rewriting everything I want to have some feedback on this change.
> 
> Kind regards,
> 
> Francesco
> 
> 
> 
> Hi Francesco,
> as a candidate future user of the proposed extension, I think I like the simplified proposal better than the original RFC.
> 
> The only part of the syntax that I would find not very much user-friendly is having to mangle the isa/mask/vlen/type list by hand.
> 
> Would a more C-like syntax be feasible ?
> E.g. something like
> 
> ```
> // AArch64 Advanced SIMD compilation
> double foo(double) __attribute__(simd_variant(“double[2] neon”,”neon_foo”));
> float64x2_t neon_foo(float64x2_t x) {…}
> 
> // x86 SSE compilation
> double foo(double) __attribute__(simd_variant(“double[2] sse”,”sse_foo”));
> __m128 sse_foo(__m128 x) {…}
> ```
> 
> ?
> 
> 
> Ciao,
> .Andrea