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

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

Hi Andrei,
> On Jun 7, 2019, at 5:46 PM, Elovikov, Andrei <andrei.elovikov at
intel.com> wrote:
>
> 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?
>
I think that the mapping between a scalar parameter and the correspondent vector
parameter(s - there can be more than one) should be handled by the Vector
Function ABI when a vector function ABI is defined.

I am working out on a new proposal, I’ll keep you posted.

I think that the requirements of 1. being a user feature 2. Based on a standard
(OpenMP), implies the fact that a contract between the scalar functions and the
vector functions must be stipulated in some document, such document being a
vector function ABI for the target.

I am crafting the attribute so that it makes it explicit that we are using
OpenMP and we are expecting a Vector Function ABI.

Kind regards,

Francesco
> Best Regards,
> Andrei
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

Hi Francesco,
> I am crafting the attribute so that it makes it explicit that we are using
OpenMP and we are expecting a Vector Function ABI.
I just thought that another option would be to force FE to always emit
"logically"-widened alwaysinline wrapper for the vector function that
does the arguments processing according to ABI inside (we need that info in the
FE anyway). That way the vectorizer pass won't need to care about the tricky
processing and we (possibly) will get a somewhat easier to understand IR after
the vectorizer.

Is that something that might work?

Thanks,
Andrei

-----Original Message-----
From: Francesco Petrogalli <Francesco.Petrogalli at arm.com> 
Sent: Monday, June 10, 2019 09:09
To: Elovikov, Andrei <andrei.elovikov at intel.com>
Cc: llvm-dev at lists.llvm.org; Saito, Hideki <hideki.saito at intel.com>
Subject: Re: [RFC] Expose user provided vector function for auto-vectorization.

Hi Andrei,
> On Jun 7, 2019, at 5:46 PM, Elovikov, Andrei <andrei.elovikov at
intel.com> wrote:
>
> 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?
>
I think that the mapping between a scalar parameter and the correspondent vector
parameter(s - there can be more than one) should be handled by the Vector
Function ABI when a vector function ABI is defined.

I am working out on a new proposal, I’ll keep you posted.

I think that the requirements of 1. being a user feature 2. Based on a standard
(OpenMP), implies the fact that a contract between the scalar functions and the
vector functions must be stipulated in some document, such document being a
vector function ABI for the target.

I am crafting the attribute so that it makes it explicit that we are using
OpenMP and we are expecting a Vector Function ABI.

Kind regards,

Francesco
> Best Regards,
> Andrei
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.