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

[Renato Golin via cfe-dev]

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/cfe-dev/attachments/20190604/c95c8acb/attachment.html>