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

[Francesco Petrogalli via llvm-dev]

Hi Andrea,

> On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at cern.ch> wrote:
> 
>  ...
> 
> 
> 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 ?

The syntax I proposed allows user to expose concepts like “linear”, “uniform” and “aligned" parameters, as described in the `declare simd` directive of OpenMP, which is what x86 and aarch64 Vector Function ABIs use to mangle the names.

I agree with you that having to manually specify the mangling is a bit cumbersome, I am open to suggestions.

An alternative approach was to make the actual string inside the attribute to accept anything a `declare variant` in a `simd` context could accept, but that wold probably raise the same problems that `declare variant` has raised.

In fact, on AArch64, a typical use of declare variant would be more complicated than just specifying `simd` in the `context`, with `simdlen` and `[not]inbranch`. It would require also to specify the `isa` trait from the `device` set, and to use a `vendor` specific set to be able to list scalable (i.e. vector-length agnostic) functions for SVE.

This would definitely look like implementing `declare variant`, as the attribute would need to accept something like the following:

```
. . . __attribute__(simd_variant(“vector_version”,“context={simd(simdlen(2),notinbranch”},device={isa(“simd")})) 
```

Using the sub-string from the mangled name to me has the following advantages:

1. No need to deal with `declare variant`.
2. Because the mangling functions are well defined, the compiler could provide warnings or errors about the expected signature of the vector function written by the user (“this parameter should be a vector of N lanes”, or, “missing masking parameter in position N …”)
3. In terms of usability, there is no need to reinvent the wheel. The `declare variant` of OpenMP 5.0 is perfectly suited for what we are doing here, it is just much more than what it is needed for exposing user-defined function to the vectorizer. So, on the long term, I think we should definitely implement `declare variant`. Whatever attribute system we came up with this RFC, it will be easy to map the `simd` bits of `declare variant` to it.

Kind regards,

Francesco

 

> 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