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

[Elovikov, Andrei via llvm-dev]

Hi All,

[I'm only subscribed to digest, so the reply doesn't look great, sorry about that]

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

Where will the mapping between parameters positions be stored? Using the example from https://software.intel.com/en-us/cpp-compiler-developer-guide-and-reference-vector-variant:

float MyAdd(float* a, int b) { return *a + b; }
__declspec(vector_variant(implements(MyAdd(float *a, int b)),      
                          linear(a), vectorlength(8),
                          nomask, processor(core_2nd_gen_avx)))
__m256 __regcall MyAddVec(float* v_a, __m128i v_b1, __m128i v_b2)

We need somehow communicate which lanes of widened "b" would map for the b1 parameter and which would go to the b2. If we only care about single ABI (like the one mandated by the OMP) than such things could be put to TTI, but what about other ABIs? Should we encode this explicitly in the annotation too?

Best Regards,
Andrei

Message: 1
Date: Mon, 3 Jun 2019 17:59:00 +0000
From: Francesco Petrogalli via llvm-dev <llvm-dev at lists.llvm.org>
To: "Doerfert, Johannes" <jdoerfert at anl.gov>
Cc: "Saito, Hideki" <hideki.saito at intel.com>, "scogland1 at llnl.gov"
	<scogland1 at llnl.gov>, LLVM Development List <llvm-dev at lists.llvm.org>,
	Clang Dev <cfe-dev at lists.llvm.org>, nd <nd at arm.com>
Subject: Re: [llvm-dev] [cfe-dev] [RFC] Expose user provided vector
	function for auto-vectorization.
Message-ID: <F7BB2A7C-EDBE-49B8-9946-12051B48A37A at arm.com>
Content-Type: text/plain; charset="utf-8"

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