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

[Andrea Bocci via cfe-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190603/9e71278a/attachment.html>