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

[Shawn Landden via llvm-dev]

On Tue, May 28, 2019 at 4:12 PM Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi Francesco,
>
> Nice to finally see this RFC, thanks! :)
>
> Overall, I like the proposal. Clean, concise and complete.
>
> I have a few comments inline, but from a high level this is looking good.
>
> On Tue, 28 May 2019 at 20:44, Francesco Petrogalli
> <Francesco.Petrogalli at arm.com> wrote:
> > The directive `#pragma clang declare variant` follows the syntax of the
> > `#pragma omp declare variant` directive of OpenMP.
> >
> > We define the new directive in the `clang` namespace instead of using
> > the `omp` one of OpenMP to allow the compiler to perform
> > auto-vectorization outside of an OpenMP SIMD context.
>
> So, the only difference is that pragma "omp" includes and links OMP
> stuff, while pragma "clang" doesn't, right?
>
> What happens if I have code with "pragma clang declare variant" and
> "pragma omp" elsewhere, would the clang pragma behave identically as
> if it was omp?
>
> >
> > The mechanism is base on OpenMP to provide a uniform user experience
> > across the two mechanism, and to maximise the number of shared
> > components of the infrastructure needed in the compiler frontend to
> > enable the feature.
> >
> > Changes in LLVM IR {#llvmIR}
> > ------------------
> >
> > The IR is enriched with metadata that details the availability of vector
> > versions of an associated scalar function. This metadata is attached to
> > the call site of the scalar function.
>
> If the metadata gets dropped by some middle-end pass, the user will be
> confused why the vector function is not being called.
>
> Do we have that problem with OMP stuff already? If so, how do we fix this?
>
>
> >     // ...
> >     ... = call double @sin(double) #0
> >     // ...
> >
> >     #0 = { vector-variant = {"_ZGVcN2v_sin(__svml_sin2),
> >                               _ZGVdN4v_sin(__svml_sin4),
> >                               ..."} }
>
> I'm assuming in all ABIs, the arguments and return values are
> guaranteed to be the same, but vector versions. Ie. there are no
> special arguments / flags / status regs that are used / changed in the
> vector version that the compiler will have to "just know". If the
> whole point is that this is a "variant", having specialist knowledge
> for random variant ABIs won't scale.
>
> Is that a problem or can we class those as "user-error"?
On architectures that have sticky floating point status flags, these
can be supported, and
my versions of exp and expf for PPC support them. I'd like to see the
compile know if
these work, because supporting them in the compiler is extra work
because you have
to re-run the calculation if you get a flag (and you care about which
specific operation caused
that flag).
-Shawn
>
> > The SVFS can add new function definitions, in the same module as the
> > `Call`, to provide vector functions that are not present within the
> > vector-variant metadata. For example, if a library provides a vector
> > version of a function with a vectorization factor of 2, but the
> > vectorizer is requesting a vectorization factor of 4, the SVFS is
> > allowed to create a definition that calls the 2-lane version twice. This
> > capability applies similarly for providing masked and unmasked versions
> > when the request does not match what is available in the library.
>
> Nice! Those thunks will play nicely with inlining later, sort of like unrolling.
>
>
> > The `construct` set in the directive, together with the `device` set, is
> > used to generate the vector mangled name to be used in the
> > `vector-variant` attribute, for example `_ZGVnN2v_sin`, when targeting
> > AArch64 Advanced SIMD code generation. The rule for mangling the name of
> > the scalar function in the vector name are defined in the the Vector
> > Function ABI specification of the target.
>
> And I assume the user is responsible for linking the libraries that
> export those signatures or they will have a linking error. Giving that
> this is user definition (in the pragma), and that we really can't know
> if the library will be available at link time, it's the only thing we
> can do.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev