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

[Doerfert, Johannes via llvm-dev]

Hi Francesco,

On 06/03, Francesco Petrogalli wrote:
> > On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at cern.ch> wrote:
> > 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 ?
> 
> The syntax I proposed allows user to expose concepts like “linear”, “uniform” and “aligned" parameters, as described in the `declare simd` directive of OpenMP, which is what x86 and aarch64 Vector Function ABIs use to mangle the names.
> 
> I agree with you that having to manually specify the mangling is a bit cumbersome, I am open to suggestions.
> 
> An alternative approach was to make the actual string inside the attribute to accept anything a `declare variant` in a `simd` context could accept, but that wold probably raise the same problems that `declare variant` has raised.
> 
> In fact, on AArch64, a typical use of declare variant would be more complicated than just specifying `simd` in the `context`, with `simdlen` and `[not]inbranch`. It would require also to specify the `isa` trait from the `device` set, and to use a `vendor` specific set to be able to list scalable (i.e. vector-length agnostic) functions for SVE.
> 
> This would definitely look like implementing `declare variant`, as the attribute would need to accept something like the following:
> 
> ```
> . . . __attribute__(simd_variant(“vector_version”,“context={simd(simdlen(2),notinbranch”},device={isa(“simd")})) 
> ```
> 
> Using the sub-string from the mangled name to me has the following advantages:
> 
> 1. No need to deal with `declare variant`.
> 2. [...]
> 3. In terms of usability, there is no need to reinvent the wheel. The
> `declare variant` of OpenMP 5.0 is perfectly suited for what we are
> doing here, it is just much more than what it is needed for exposing
> user-defined function to the vectorizer. So, on the long term, I think
> we should definitely implement `declare variant`. Whatever attribute
> system we came up with this RFC, it will be easy to map the `simd`
> bits of `declare variant` to it.

I'm unsure about this. While I agree that avoiding to deal with "declare
variant" will make this all much easier, you seem to agree that we will
eventually have to do that anyway. Adding something now that is a subset
of what we will need will put as in an awkward position. We will have to
unify the existing in-house concept with the standardized OpenMP way in
terms of semantics as well as implementation. I somehow doubt that this
will make things easier, especially if we later discover that the
in-house solution is somehow incompatible or not actually a subset.

To summarize: I will not oppose this effort but I would much rather see
us working towards "declare variant", a stronger concept we will have to
support in the near future anyway.

Thanks,
  Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190604/8f4fcd6b/attachment.sig>