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

Doerfert, Johannes via llvm-dev llvm-dev at lists.llvm.org
Fri May 31 16:19:06 PDT 2019


On 05/31, Francesco Petrogalli wrote:
> 
> 
> > On May 31, 2019, at 3:31 PM, Doerfert, Johannes <jdoerfert at anl.gov> wrote:
> > 
> > On 05/31, Saito, Hideki wrote:
> >> 
> >>> This works for variants that are created from definitions in the module but what about #omp declare simd declarations?
> >> 
> >> I'm sorry that I haven't digested this thread in its entirety, but let 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)
> > 
> 
> I understand what you mean. You are concerned about what happens when we will have to fully implement `declare variant` and support other context than the `simd` one.
> 
> I thought that this concern was handled by a paragraph in the RFC, but I guess I forgot to add it.
> 
> In any case, to fully support `declare variant`, we will have to :
> 
> 1. Either extend the attribute `vector-variant` in the IR ,
> 2. Or come up with a new attribute that combines what `vector-variant` says with the additional context information provided by the pragma.
> 
> My favorite is 2.
> 
> But this is not part of this RFC.
> 
> @Johannes, is it enough for you if I make it explicit that the `vector-variant` is only for the SIMD context of the `declare variant`?

That is one of my concerns, yes. I have listed more in the other
thread, e.g., module merging.

I'm would prefer not to go through this process (RFC, discussion,
upstreaming, fixing, ...) for a subset of what we need to support only
to redefine an unknown subset once someone finds the time to implement
declare variant.
-------------- 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/20190531/83769312/attachment.sig>


More information about the llvm-dev mailing list