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

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/llvm-dev/attachments/20190603/9e71278a/attachment.html>

Hi Francesco,

Whatever we end up doing, even if not a direct implementation of omp 5,
should be of identical behaviour, or at least a subset.

I think both you and Alexey agree with that, I'm just making sure this is
said out loud, before we start getting different proposals and derail this
thread.

We are not in the business of inventing new standards, but of implementing
existing ones. Standards that work across languages and hardware are really
hard to get right and having local (different) features competing with them
will not help users in the long run.

Implementation defined behaviour should also be consistent and compatible
with prior art (other compilers) as we want to follow the path of least
friction. Mangling will have side effects at link time, so picking any
random one, no matter how much better it looks now, could lead to long term
conflicts.

Spending a bit more time now could save us a lot of time in the future.

Cheers,
Renato

On Mon, 3 Jun 2019, 20:25 Francesco Petrogalli via llvm-dev, <
llvm-dev at lists.llvm.org> wrote:
> +CC Alexey B.
>
> > On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at
cern.ch> wrote:
> >
> > 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190604/c95c8acb/attachment.html>

Hi Francesco,

On 06/03, Francesco Petrogalli wrote:
> > On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at
cern.ch> wrote:
> > 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. [...]
> 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.
I'm unsure about this. While I agree that avoiding to deal with
"declare
variant" will make this all much easier, you seem to agree that we will
eventually have to do that anyway. Adding something now that is a subset
of what we will need will put as in an awkward position. We will have to
unify the existing in-house concept with the standardized OpenMP way in
terms of semantics as well as implementation. I somehow doubt that this
will make things easier, especially if we later discover that the
in-house solution is somehow incompatible or not actually a subset.

To summarize: I will not oppose this effort but I would much rather see
us working towards "declare variant", a stronger concept we will have
to
support in the near future anyway.

Thanks,
  Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190604/8f4fcd6b/attachment.sig>