search for: _zgv

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

...me just deal with this one point for now. > Suppose #pragma omp declare simd is applied to foo(). I'd expect the corresponding Function Attrs to be attached to > "declare dso_local void @foo(i32)". For Intel vector function ABI, the attribute comes with a mangled name like "_ZGV........foo". OK. And we will do the same for #omp declare variant match(simd=...), right? What if we have #omp declare variant match(parallel, simd=...)? (My syntax might be off, if you don't understand what I mean, please let me know and I correct the syntax) > --------------------...

...ed 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 &g...

...ct, there > >> is already common ground between the x86 and aarch64 backend, who have > >> based their respective Vector Function ABI specifications on OpenMP. > >> > >> In fact, the mangled name grammar can be summarized as follows: > >> > >> _ZGV<isa><masking><VLEN><parameter type>_<scalar name> > >> > >> Across vector extensions the only <token> that will differ is the > >> <isa> token. > >> > >> This might lead people to think that we could drop the _...

...MP. I hear the argument on having some common ground here. In fact, there is already common ground between the x86 and aarch64 backend, who have based their respective Vector Function ABI specifications on OpenMP. > > In fact, the mangled name grammar can be summarized as follows: > > _ZGV<isa><masking><VLEN><parameter type>_<scalar name> > > Across vector extensions the only <token> that will differ is the <isa> token. > > This might lead people to think that we could drop the _ZGV<isa> prefix and consider the <masking...

...g some common ground here. In fact, there is already common ground between the x86 and aarch64 backend, who have based their respective Vector Function ABI specifications on OpenMP. >>> >>> In fact, the mangled name grammar can be summarized as follows: >>> >>> _ZGV<isa><masking><VLEN><parameter type>_<scalar name> >>> >>> Across vector extensions the only <token> that will differ is the <isa> token. >>> >>> This might lead people to think that we could drop the _ZGV<isa> pre...

...ct, there is already common ground between the x86 and aarch64 backend, who have based their respective Vector Function ABI specifications on OpenMP. >>>>> >>>>> In fact, the mangled name grammar can be summarized as follows: >>>>> >>>>> _ZGV<isa><masking><VLEN><parameter type>_<scalar name> >>>>> >>>>> Across vector extensions the only <token> that will differ is the <isa> token. >>>>> >>>>> This might lead people to think that we co...

...ot; call that prevent the vectorization of the k loop. The expected vector loop (shown as pseudo code, ignoring leftover iterations) resulting from LLVM's LoopVectorizer is ... ... vectorized_for (k = 0; k < 4096; k += VL) { a[k:VL] = {k, k+1, k+2, k+VL-1} * 0.5; a[k:VL] = _ZGVb4Nul_dowork(a, k); } ... ... In this example "_ZGVb4Nul_dowork" is a special name mangling where: _ZGV is a prefix based on C/C++ name mangling rule suggested by GCC community, 'b' indicates "xmm" (assume we vectorize here to 128bit xmm vector registers), '4&...

...ing the body of the scalar function. To be more precise: VecClone strictly deals with the callee side of the code. Caller side mapping happens in vectorizer (LoopVectorize for the most part, but I don't see why SLPVectorize can't, for example). Starting from the scalar code, for each "_ZGV..." name it finds in the function attribute, VecClone will create a new function definition with that _ZGV... name, with the function body of the scalar code surrounded by a constant trip loop (trip count is part of the mangled function name) and then massage the function body. Once the IR for...

...nd between the x86 and aarch64 backend, who have based their respective Vector Function ABI specifications on OpenMP. >>>>>>> >>>>>>> In fact, the mangled name grammar can be summarized as follows: >>>>>>> >>>>>>> _ZGV<isa><masking><VLEN><parameter type>_<scalar name> >>>>>>> >>>>>>> Across vector extensions the only <token> that will differ is the <isa> token. >>>>>>> >>>>>>> This might...

...the argument on having some common ground here. In fact, there > is already common ground between the x86 and aarch64 backend, who have > based their respective Vector Function ABI specifications on OpenMP. > > In fact, the mangled name grammar can be summarized as follows: > > _ZGV<isa><masking><VLEN><parameter type>_<scalar name> > > Across vector extensions the only <token> that will differ is the > <isa> token. > > This might lead people to think that we could drop the _ZGV<isa> > prefix and consider the &...

...by the following >>>>>> IR. >>>>>> >>>>>> // ... >>>>>> ... = call double @sin(double) #0 >>>>>> // ... >>>>>> >>>>>> #0 = { vector-variant = {"_ZGVcN2v_sin(__svml_sin2), >>>>>> _ZGVdN4v_sin(__svml_sin4), >>>>>> ..."} } >>>>>> >>>>>> The string `"_ZGVcN2v_sin(__svml_sin2)"` in this vector-variant...

...nd aarch64 > > >>>> backend, who have based their respective Vector Function ABI specifications on OpenMP. > > >>>> > > >>>> In fact, the mangled name grammar can be summarized as follows: > > >>>> > > >>>> _ZGV<isa><masking><VLEN><parameter type>_<scalar name> > > >>>> > > >>>> Across vector extensions the only <token> that will differ is > > >>>> the <isa> token. > > >>>> > > >&gt...

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

...ization of the k loop. > > The expected vector loop (shown as pseudo code, ignoring leftover > iterations) resulting from LLVM's LoopVectorizer is > > ... ... > vectorized_for (k = 0; k < 4096; k += VL) { > a[k:VL] = {k, k+1, k+2, k+VL-1} * 0.5; > a[k:VL] = _ZGVb4Nul_dowork(a, k); > } > ... ... > > In this example "_ZGVb4Nul_dowork" is a special name mangling where: > _ZGV is a prefix based on C/C++ name mangling rule suggested by GCC > community, 'b' indicates "xmm" (assume we vectorize here to 128bit xmm...

...ground between the x86 and aarch64 > >>>> backend, who have based their respective Vector Function ABI specifications on OpenMP. > >>>> > >>>> In fact, the mangled name grammar can be summarized as follows: > >>>> > >>>> _ZGV<isa><masking><VLEN><parameter type>_<scalar name> > >>>> > >>>> Across vector extensions the only <token> that will differ is the > >>>> <isa> token. > >>>> > >>>> This might lead...

> On Mar 2, 2016, at 1:33 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 2 March 2016 at 01:14, John McCall via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, all. >> - We sometimes want to return more values in registers than the convention normally does, and we want to be able to use both integer and floating-point registers. For