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

[Francesco Petrogalli via cfe-dev]

> On May 31, 2019, at 3:15 PM, Alexey Bataev <a.bataev at hotmail.com> wrote:
> 
> In this case, we can reuse the same attribute for both, omp directive and clang variant attribute.
> 

Let me summarize what we seem to be converging towards:


FRONTEND

```
#pragma omp declare variant(vector_foo) match(context-matchers)
double foo(double);

Vector_double vector_foo(vector_double)
```

Equivalent to a clang specific attribute

```
double foo(double) __attribute__(declare_variant(vector_foo, context-matchers));
```

The content-matchers will be the same, and the parsing mechanisms shared among the function attribute in C and the omp directive.

For now, we teach clang only about the variant in a `context=simd()`.

MIDEND (IR)

We use an attribute, vector-variant, to represent the information that the frontend will be handling:

#attribute #0 = {vector-variants=“_ZGV…_foo(vector_foo), …."}

The same attribute is used by both `declare variant` and `declare simd`, the only difference being that for `declare simd` there is no custom name redirection via the `(vector_foo)` token.

NAME MANGLING

We live with the name mangling of the vector function ABI of the target. If OpenMP comes up with a new name mangling convention, we will discuss whether we want to support that too.

EXTENDING TO FUL SUPPORT OF `declare variant`

That is not part of this RFC. With this RFCm the frontent will generate the `vector-variant` attribute that is limited only for auto-vectorization in a SIMD context. Other  aspect of `declare variant` will be handled in a separate RFC.



> Best regards,
> Alexey Bataev