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

Tue Jun 4 10:09:54 PDT 2019

Hi renato

> On Jun 4, 2019, at 1:55 AM, Renato Golin <rengolin at gmail.com> wrote:
> 
> 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.
> 

Yep, this is a very good reminder.

> 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.
> 

+1

> 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.
> 

+1 here too. With the additional comment that Vector Function ABI specifications are written with the criteria of:

1. Exposing all architectural features that are needed to have a good (if not optimal) way of interfacing binaries.
2. Don’t create conflicts, which equals to guarantee backward compatibility.

It is the same as the calling conventions of a target. They are not supposed to change, and if they ever do, they must guarantee backwards compatibility.

I believe that using Vector Function ABIs for interfacing the compiler with vector function is the right think to do. Future proof and compatible across compilers.

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

+1 here too, this is exactly what we are doing :)

Thank you,

Francesco

> 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