[cfe-dev] RFC: Interface user provided vector functions with the vectorizer.
Doerfert, Johannes via cfe-dev
cfe-dev at lists.llvm.org
Mon Jun 24 08:48:49 PDT 2019
@Xinmin, Saito: If Clang/the frontend generates the version there is no problem, or is there? The frontend knows about the original source type and it's ABI specific lowering already.
@Francesco, we should even consider putting the generating capabilities outside of the OpenMP code generation (in the future). That could allow easier reuse by other frontends.
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Tian, Xinmin <xinmin.tian at intel.com>
Sent: Monday, June 24, 2019 5:28:45 PM
To: Saito, Hideki; Francesco Petrogalli; Doerfert, Johannes
Cc: Simon Moll; LLVM Development List; Clang Dev; Renato Golin; Finkel, Hal J.; Andrea Bocci; Elovikov, Andrei; Alexey Bataev; nd; Roman Lebedev; Philip Reames; Shawn Landden
Subject: RE: RFC: Interface user provided vector functions with the vectorizer.
>>>>I don’t know if this is going to be a problem for other architectures
++++++I haven't checked what IA-32/Intel64 should do for type 2, but I fully agree that this needs to be done properly according to the ABI.
Agreed. It looks we have an issue here. Given this is parameter, could we use metadata or attribute to preserve the "struct" info, in ICC, we called BE type saved info in the symtab.
Xinmin
-----Original Message-----
From: Saito, Hideki
Sent: Friday, June 21, 2019 4:44 PM
To: Francesco Petrogalli <Francesco.Petrogalli at arm.com>; Doerfert, Johannes <jdoerfert at anl.gov>
Cc: Simon Moll <moll at cs.uni-saarland.de>; LLVM Development List <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at lists.llvm.org>; Renato Golin <rengolin at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>; Andrea Bocci <andrea.bocci at cern.ch>; Elovikov, Andrei <andrei.elovikov at intel.com>; Alexey Bataev <a.bataev at hotmail.com>; Tian, Xinmin <xinmin.tian at intel.com>; nd <nd at arm.com>; Roman Lebedev <lebedev.ri at gmail.com>; Philip Reames <listmail at philipreames.com>; Shawn Landden <slandden at gmail.com>
Subject: RE: RFC: Interface user provided vector functions with the vectorizer.
>In all cases, the IR type of the parameters in `foo` is i64, therefore is not possible to distinguish what C type generated the signature of `foo`.
Ouch.
>I don’t know if this is going to be a problem for other architectures
I haven't checked what IA-32/Intel64 should do for type 2, but I fully agree that this needs to be done properly according to the ABI.
>Therefore, I would like to propose a change to the RFC, which would move the responsibility off generating the vector function signature from LLVM to clang.
Makes sense to me.
-----Original Message-----
From: Francesco Petrogalli [mailto:Francesco.Petrogalli at arm.com]
Sent: Friday, June 21, 2019 2:04 PM
To: Doerfert, Johannes <jdoerfert at anl.gov>
Cc: Simon Moll <moll at cs.uni-saarland.de>; LLVM Development List <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at lists.llvm.org>; Renato Golin <rengolin at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>; Andrea Bocci <andrea.bocci at cern.ch>; Elovikov, Andrei <andrei.elovikov at intel.com>; Alexey Bataev <a.bataev at hotmail.com>; Saito, Hideki <hideki.saito at intel.com>; Tian, Xinmin <xinmin.tian at intel.com>; nd <nd at arm.com>; Roman Lebedev <lebedev.ri at gmail.com>; Philip Reames <listmail at philipreames.com>; Shawn Landden <slandden at gmail.com>
Subject: Re: RFC: Interface user provided vector functions with the vectorizer.
Hi all - I am working with a colleague to provide an initial implementation of this.
We encountered a problem when dealing with generating the vector signatures of functions that use complex data.
In this proposal, we expect the SVFS component in the backed to demangle the name of the function in the attribute to be able to reconstruct the signature of the vector function from the scalar function signature.
In case of Complex data, this doesn’t seem to be possible, because the information of “being a vector of 2 lanes” that is supposed to be carried by the complex scalar is lost in the transformation the data type in a “coerced” type.
Consider these three types and the function `foo`:
// Type 1
typedef _Complex int S;
// Type 2
typedef struct x{
int a;
int b;
} S;
// Type 3
typedef uint64_t S;
S foo(S a, S b) {
return ...;
}
In all cases, the IR type of the parameters in `foo` is i64, therefore is not possible to distinguish what C type generated the signature of `foo`.
I don’t know if this is going to be a problem for other architectures, but this is definitely a problem on AArch64 where we need to be able to generate the correct vector function signature for a specific simdlen(N) attached on `foo`. When simdlen(2), for type 1 the vector type is <4 x i32>, for type 2 is <2 x i64*>, for type 3 is <2 x i64>.
Therefore, I would like to propose a change to the RFC, which would move the responsibility off generating the vector function signature from LLVM to clang.
In particular, (and this I believe has already been mentioned by Johannes), we could use the @llvm.compiler.used intrinsic to mark those declaration that needs to stay in the IR and not optimized away OPT before reaching the vectorizer.
In summary, the change would consist of:
1. Generate symbols declaration/definitions of the vector function with the mangled name in the IR, and mark it with @llvm-compiler.used. This could be done in CGOpenMPRuntime.cpp 2. Use the attribute vector-abs-variant defined in this RFC to map scalar names to vector ABI mangled name, and used the same redirection mechanism for the user provided vector name.
3. Move the “vector function signature generation” from the SVFS in LLVM to the openmp code generator of the clang frontend
The SVFS query system would still work as in the current proposal. The only difference is that the vector function signature would be given by the frontend and not need to be recomputed.
Here is an example of ho the IR would look like with this change:
```
@llvm.compiler.used = appending global [1 x i8*] [i8* bitcast (<2 x i32> (<2 x i32>)* @f to i8*)], section "llvm.metadata"
declare dso_local <2 x i32> @_ZGVnN2v_foo(<2 x i32> returned)
declare i32 @foo(i32) #0
; other function definition, including the one provided by the user `my_vector_foo` if the user provided a definition and not just the declaration
attribute #0 = {vector-function-abi-variant=“_ZGVnN2v_foo(my_vector_foo)"}
```
If the attribute @llvm.compiler.used is not suitable for this (I am not aware of all implication of using it on a global symbol), maybe we could come up with a intrinsics that does what we need (avoid deleting declarations that are not used) and name it @llvm.vector.function.used?
Please let me know what you think, I will submit an updated proposal next week.
Kind regards,
Francesco
> On Jun 17, 2019, at 7:05 AM, Doerfert, Johannes <jdoerfert at anl.gov> wrote:
>
> I agree with Simon. This looks good conceptually. I have minor implementation comments but that can wait till the code reviews.
>
> Sorry for the delay and thanks for working on this.
>
> Get Outlook for Android
>
> From: Simon Moll <moll at cs.uni-saarland.de>
> Sent: Monday, June 17, 2019 10:02:58 AM
> To: Francesco Petrogalli; LLVM Development List; Clang Dev
> Cc: Renato Golin; Finkel, Hal J.; Andrea Bocci; Elovikov, Andrei;
> Alexey Bataev; Doerfert, Johannes; Saito, Hideki; Tian, Xinmin; nd;
> Roman Lebedev; Philip Reames; Shawn Landden
> Subject: Re: RFC: Interface user provided vector functions with the vectorizer.
>
> Hi Francesco,
>
> On 6/11/19 10:55 PM, Francesco Petrogalli wrote:
> > Dear all,
> >
> > I have re-written the proposal for interfacing user provided vector
> > functions, originally posted in both llvm-dev and cfe-dev mailing
> > list:
> >
> > "[RFC] Expose user provided vector function for auto-vectorization."
> >
> > The proposal looks quite different from the original submission,
> > therefore I took the liberty to start a new thread.
> >
> > The original thread generated some good discussion. In particular,
> > Simon Moll and Johannes Doerfert (CCed) have managed to provide good
> > arguments for the following claims:
> >
> > 1. The Vector Function ABI name mangling scheme of a target is not
> > enough to describe all uses cases of function vectorization that
> > the compiler might end up needing to support in the future.
> I think the new name of the attribute makes this point clear.
> > 2. `declare variant` needs to be handled properly at IR level, to be
> > able to give the compiler the full OpenMP context of the directive.
> >
> > This proposal addresses those two concerns and other (I believe)
> > minor concerns that have been raised in the previous thread.
> >
> > This proposal is provided with examples and a self assessment around
> > extendibility.
> >
> > I have CCed all the people that have participated in the discussion
> > so far, please let me know if you think I have missed anything of
> > what have been raised.
> >
> > Kind regards,
> >
> > Francesco
>
> LGTM. Please add me as a reviewer for this when you post patches.
>
> Thanks!
>
> Simon
>
> >
> > *** DRAFT OF THE PROPOSAL ***
> >
> > # SCOPE OF THE RFC : Interface user provided vector functions with the vectorizer.
> >
> > Because the users care about portability (across compilers,
> > libraries and systems), I believe we have to base sour solution on a
> > standard that describes the mapping from the scalar function to the
> > vector function.
> >
> > Because OpenMP is standard and widely used, we should base our
> > solution on the mechanisms that the standard provides, via the
> > directives `declare simd` and `declare variant`, the latter when
> > used in with the `simd` trait in the `construct` set.
> >
> > Please notice that:
> >
> > 1. The scope of the proposal is not implementing full support for
> > `pragma omp declare variant`.
> > 2. The scope of the proposal is not enabling the vectorizer to do new
> > kind of vectorizations (e.g. RV-like vectorization described by
> > Simon).
> > 3. The proposal aims to be extendible wrt 1. and 2.
> > 4. The IR attribute introduced in this proposal is equivalent to the
> > one needed for the VecClone pass under development in
> > https://reviews.llvm.org/D22792
> >
> > # CLANG COMPONENTS
> >
> > A C function attribute, `clang_declare_simd_variant`, to attach to
> > the scalar version. The attribute provides enough information to the
> > compiler about the vector shape of the user defined function. The
> > vector shapes handled by the attribute are those handled by the
> > OpenMP standard via `declare simd` (and no more than that).
> >
> > 1. The function attribute handling in clang is crafted with the
> > requirement that it will be possible to re-use the same components
> > for the info generated by `declare variant` when used with a `simd`
> > traits in the `construct` set.
> > 2. The attribute allows orthogonality with the vectorization that is
> > done via OpenMP: the user vector function is still exposed for
> > vectorization when not using `-fopenmp-[simd]` once the `declare
> > simd` and `declare variant` directive of OpenMP will be available
> > in the front-end.
> >
> > ## C function attribute: `clang_declare_simd_variant`
> >
> > The definition of this attribute has been crafted to match the
> > semantics of `declare variant` for a `simd` construct described in
> > OpenMP 5.0. I have added only the traits of the `device` set, `isa`
> > and `arch`, which I believe are enough to cover for the use case of
> > this proposal. If that is not the case, please provide an example,
> > extending the attribute will be easy even once the current one is
> > implemented.
> >
> > ```
> > clang_declare_simd_variant(<variant-func-id>, <simd clauses>{,
> > <context selector clauses>})
> >
> > <variant-func-id>:= The name of a function variant that is a base language identifier, or,
> > for C++, a template-id.
> >
> > <simd clauses> := <simdlen>, <mask>{, <optional simd clauses>}
> >
> > <simdlen> := simdlen(<positive number>) | simdlen("scalable")
> >
> > <mask> := inbranch | notinbranch
> >
> > <optional simd clauses> := <linear clause>
> > | <uniform clause>
> > | <align clause> | {,<optional simd
> > clauses>}
> >
> > <linear clause> := linear_ref(<var>,<step>)
> > | linear_var(<var>, <step>)
> > | linear_uval(<var>, <step>)
> > | linear(<var>, <step>)
> >
> > <step> := <var> | <non zero number>
> >
> > <uniform clause> := uniform(<var>)
> >
> > <align clause> := align(<var>, <positive number>)
> >
> > <var> := Name of a parameter in the scalar function
> > declaration/definition
> >
> > <non zero number> := ... | -2 | -1 | 1 | 2 | ...
> >
> > <positive number> := 1 | 2 | 3 | ...
> >
> > <context selector clauses> := {<isa>}{,} {<arch>}
> >
> > <isa> := isa(target-specific-value)
> >
> > <arch> := arch(target-specific-value)
> >
> > ```
> >
> > # LLVM COMPONENTS:
> >
> > ## VectorFunctionShape class
> >
> > The object `VectorFunctionShape` contains the information about the
> > kind of vectorization available for an `llvm::Call`.
> >
> > The object `VectorFunctionShape` must contain the following information:
> >
> > 1. Vectorization Factor (or number or concurrent lanes executed by the
> > SIMD version of the function). Encoded by unsigned integer.
> > 2. Whether the vector function is requested for scalable
> > vectorization, encoded by a boolean.
> > 3. Information about masking / no masking, encoded by a boolean.
> > 4. Information about the parameters, encoded in a container that
> > carries objects of type `ParamaterType`, to describe features like
> > `linear` and `uniform`.
> > 5. Function name redirection, if a user has specified to use a custom
> > name instead of the Vector Function ABI ones.
> >
> > Items 1. to 5. represents the information stored in the
> > `vector-function-abi-variant` attribute (see next section).
> >
> > The object can be extended in the future to include new
> > vectorization kinds (for example the RV-like vectorization of the
> > Region Vectorizer), or to add more context information that might
> > come from other uses of OpenMP `declare variant`, or to add new
> > Vector Function ABIs not based on OpenMP. Such information can be
> > retrieved by attributes that will be added to describe the `Call` instance.
> >
> > ## IR Attribute
> >
> > We define a `vector-function-abi-variant` attribute that lists the
> > mangled names produced via the mangling function of the Vector
> > Function ABI rules.
> >
> > ```
> > vector-function-abi-variant = "abi_mangled_name_01, abi_mangled_name_02(user_redirection),..."
> > ```
> >
> > 1. Because we use only OpenMP `declare simd` vectorization, and
> > because we require a vector Function ABI, we make this explicit
> > in the name of the attribute.
> > 2. Because the Vector Function ABIs encode all the information
> > needed to know the vectorization shape of the vector function in
> > the mangled names, we provide the mangled name via the
> > attribute.
> > 3. Function names redirection is specified by enclosing the name of
> > the redirection in parenthesis, as in
> > `abi_mangled_name_02(user_redirection)`.
> >
> > ## Vector ABI Demangler
> >
> > The “Vector ABI demangler”, is the component that demangles the data
> > in the `vector-function-abi-variant` attribute and that provides the
> > instances of the class `VectorFunctionShape` that can be derived by
> > the mangled names listed in the attribute.
> >
> > ## Query interface: Search Vector Function System (SVFS)
> >
> > An interface that can be queried by the LLVM components to
> > understand whether or not a scalar function can be vectorized, and
> > that retrieves the vector function to be used if such vector shape is available.
> >
> > 1. This component is going to be unrelated to OpenMP.
> > 2. This component will use internally the demangler defined in the
> > previous section, but it will not expose any aspect of the Vector
> > Function ABI via its interface.
> >
> > The interface provides two methods.
> >
> > ```
> > std::vector<VectorFunctionShape>
> > SVFS::isFunctionVectorizable(llvm::CallInst * Call);
> >
> > llvm::Function * SVFS::getVectorizedFunction(llvm::CallInst * Call,
> > VectorFunctionShape Info); ```
> >
> > The first method is used to list all the vector shapes that
> > available and attached to a scalar function. An empty results means
> > that no vector versions are available.
> >
> > The second method retrieves the information needed to build a call
> > to a vector function with a specific `VectorFunctionShape` info.
> >
> > # (SELF) ASSESSMENT ON EXTENDIBILITY
> >
> >
> > 1. Extending the C function attribute `clang_declare_simd_variant` to
> > new Vector Function ABIs that use OpenMP will be straightforward
> > because the attribute is tight to such ABIs and OpenMP.
> > 2. The C attribute `clang_declare_simd_variant` and the `declare
> > variant` directive used for the `simd` trait will be sharing the
> > internals in clang, so adding the OpenMP functionality for `simd`
> > traits will be mostly handling the directive in the OpenMP
> > parser. How this should be done is described in
> >
> > https://clang.llvm.org/docs/InternalsManual.html#how-to-add-an-attri
> > bute 3. The IR attribute `vector-function-abi-variant` is not to be
> > extended to represent other kind of vectorization other than those
> > handled by `declare simd` and that are handled with a Vector
> > Function ABI.
> > 4. The IR attribute `vector-function-abi-variant` is not defined to be
> > extended to represent the information of `declare variant` in its
> > totality.
> > 5. The IR attribute will not need to change when we will introduce non
> > vector function ABI vectorization (RV-like, reductions...) or when
> > we will decide to fully support `declare variant`. The information
> > it carries will not need to be invalidated, but just extended with
> > new attributes that will need to be handled by the
> > `VectorFunctionShape` class, in a similar way the
> > `llvm::FPMathOperator` does with the `llvm::FastMathFlags`, which
> > operates on individual attributes to describe an overall
> > functionality.
> >
> > # Examples
> >
> > ## Example 1
> >
> > Exposing an Advanced SIMD vector function when targeting Advanced
> > SIMD in AArch64.
> >
> > ```
> > double foo_01(double Input)
> > __attribute__(clang_declare_simd_variant(“vector_foo_01",
> > simdlen(2), notinbranch, isa("simd"));
> >
> > // Advanced SIMD version
> > float64x2_t vector_foo_01(float64x2_t VectorInput); ```
> >
> > The resulting IR attribute is:
> >
> > ```
> > attribute #0 = {vector-abi-variant="_ZGVnN2v_foo_01(vector_foo_01)"}
> > ```
> >
> > ## Example 2
> >
> > Exposing an Advanced SIMD vector function when targeting Advanced
> > SIMD in AArch64, but with the wrong signature. The user specifies a
> > masked version of the function in the clauses of the attribute, the
> > compiler throws an error suggesting the signature expected for
> > ``vector_foo_02.``
> >
> > ```
> > double foo_02(double Input)
> > __attribute__(clang_declare_simd_variant(“vector_foo_02",
> > simdlen(2), inbranch, isa("simd"));
> >
> > // Advanced SIMD version
> > float64x2_t vector_foo_02(float64x2_t VectorInput);
> > // (suggested) compiler error -> ^ Missing mask parameter of type `uint64x2_t`.
> > ```
> >
> > ## Example 3
> >
> > Targeting `sincos`-like signatures.
> >
> > ```
> > void foo_03(double Input, double * Output)
> > __attribute__(clang_declare_simd_variant(“vector_foo_03",
> > simdlen(2), notinbranch, linear(Output, 1), isa("simd"));
> >
> > // Advanced SIMD version
> > void vector_foo_03(float64x2_t VectorInput, double * Output); ```
> >
> > The resulting IR attribute is:
> >
> > ```
> > attribute #0 =
> > {vector-abi-variant="_ZGVnN2vl8_foo_03(vector_foo_03)"}
> > ```
> > ## Example 4
> >
> > Scalable vectorization targeting SVE
> >
> > ```
> > double foo_04(double Input)
> > __attribute__(clang_declare_simd_variant(“vector_foo_04",
> > simdlen("scalable"), notinbranch, isa("sve"));
> >
> > // SVE version
> > svfloat64_t vector_foo_04(svfloat64_t VectorInput, svbool_t Mask);
> > ```
> >
> > The resulting IR attribute is:
> >
> > ```
> > attribute #0 = {vector-abi-variant="_ZGVsM2v_foo_04(vector_foo_04)"}
> > ```
> >
> > ## Example 5
> >
> > Fixed length vectorization targeting SVE
> >
> > ```
> > double foo_05(double Input)
> > __attribute__(clang_declare_simd_variant(“vector_foo_05",
> > simdlen(4), inbranch, isa("sve"));
> >
> > // Fixed-length SVE version
> > svfloat64_t vector_foo_05(svfloat64_t VectorInput, svbool_t Mask);
> > ```
> >
> > The resulting IR attribute is:
> >
> > ```
> > attribute #0 = {vector-abi-variant="_ZGVsM2v_foo_04(vector_foo_04)"}
> > ```
> >
> > ## Example 06
> >
> > This is an x86 example, equivalent to the one provided by Andrei
> > Elovikow in
> > http://lists.llvm.org/pipermail/llvm-dev/2019-June/132885.html.
> > Godbolt rendering with ICC at https://godbolt.org/z/Of1NxZ
> >
> > ```
> > float MyAdd(float* a, int b)
> > __attribute__(clang_declare_simd_variant(“MyAddVec", simdlen(8), notinbranch, arch("core_2nd_gen_avx")) {
> > return *a + b;
> > }
> >
> >
> > __m256 MyAddVec(float* v_a, __m128i v_b1, __m128i v_b2); ```
> >
> > The resulting IR attribute is:
> >
> > ```
> > attribute #0 = {vector-abi-variant="_ZGVbN8l4v_MyAdd(MyAddVec)"}
> > ```
> >
> > ## Example showing interaction with `declare simd`
> >
> > ```
> > #pragma omp declare simd linear(a) notinbranch float foo_06(float
> > *a, int x) __attribute__(clang_declare_simd_variant(“vector_foo_06", simdlen(4), linear(a), notinbranch, arch("armv8.2-a+simd")) {
> > return *a + x;
> > }
> >
> > // Advanced SIMD version
> > float32x4_t vector_foo_06(float *a, int32x4_t vx) { // Custom
> > implementation.
> > }
> > ```
> >
> > The resulting IR attribute is made of three symbols:
> >
> > 1. `_ZGVnN2l4v_foo_06` and `_ZGVnN4l4v_foo_06`, which represent the
> > ones the compiler builds by auto-vectorizing `foo_06` according to
> > the rule defined in the Vector Function ABI specifications for
> > AArch64.
> > 2. `_ZGVnN4l4v_foo_06(vector_foo_06)`, which represents the
> > user-defined redirection of the 4-lane version of `foo_06` to the
> > custom implementation provided by the user when targeting Advanced
> > SIMD for version 8.2 of the A64 instruction set.
> >
> > ```
> > attribute #0 =
> > {vector-function-abi-variant="_ZGVnN2l4v_foo_06,_ZGVnN4l4v_foo_06,_Z
> > GVnN4l4v_foo_06(vector_foo_06)"}
> > ```
> >
> --
>
> Simon Moll
> Researcher / PhD Student
>
> Compiler Design Lab (Prof. Hack)
> Saarland University, Computer Science
> Building E1.3, Room 4.31
>
> Tel. +49 (0)681 302-57521 : moll at cs.uni-saarland.de Fax. +49 (0)681
> 302-3065 : http://compilers.cs.uni-saarland.de/people/moll
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190624/8b124afe/attachment.html>
More information about the cfe-dev
mailing list