[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

[Alexander Musman]

Thanks for working on this. I expect that stmts are emitted without
reordering by clang, though may be there are some corner cases I do not
know about.
I attached a clang patch for experiments - it adds "!"safelen" !LoopId Len
N" metadata for loops with "omp simd safelen(Len)" (see
test/OpenMP/simd_metadata.c for example). You will also need to change
"safelen" to whatever metadata name we'll come up with.

Thanks,
Alexander


2014-08-20 21:57 GMT+04:00 Robison, Arch <arch.robison at intel.com>:

> > We must do this directly in the frontend. Relying on another
> > pass run early would be bad because it would introduce a hard-to-enforce
> > contract affecting correctness.
>
> Instead of a pass, the marking could be a utility routine that client
> front ends can run?  Or maybe it's not a big deal.  I guess I'll find out
> when I modify the Julia front-end :-)
>
> > Also, we should probably allow for missing access numbers, so long
> > as everything is in order (because the optimizer might eliminate some of
> them).
> > Some memory-access instructions might also have more than one access
> number
> > (after GVN, vectorization, etc.), and we should allow for that.
>
> I concur that holes and duplicates should be allowed.
>
> - Arch Robison
>   Intel Corporation
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/c3cde653/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang_safelen_marking
Type: application/octet-stream
Size: 6624 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/c3cde653/attachment.obj>