add llvm.mem.parallel_loop_access?

[hfinkel]

Do the semantics of the omp simd construct allow us to add the ‘llvm.mem.parallel_loop_access‘ metadata to the memory accesses in a simd parallel loop? I think this is equivalent to have an infinite safelen.

[amusman]

Hi Hal,

I believe this is too optimistic and will need some rework (and maybe changes in metadata semantics too). I think the idea was, when clause 'safelen' is present, it should limit vector width by passing 'llvm.vectorizer.width', but this also may be unsafe, if ‘llvm.mem.parallel_loop_access‘ metadata would be used somewhere without respect to 'llvm.vectorizer.width'...

[hfinkel]

I think you're definitely correct, we could not use llvm.mem.parallel_loop_access with any finite safelen (as currently implemented). However, we also need to be careful, even in the current implementation, that the 'safelen' also appropriately restricts the interleaved post-vectorization unrolling. This just occurred to me, so I've not given it much thought, but we likely have a problem with that now.

To my original question, however, is no safelen clause equivalent to an infinite safelen? If so, could we add llvm.mem.parallel_loop_access when no safelen is present?

[amusman]

Yes, in this case (when there is no 'safelen' clause) adding llvm.mem.parallel_loop_access should be safe (safelen is implementation-defined, and thus may be infinite). I'll prepare a fix for the case with finite safelen, thanks for pointing it out.

[hfinkel]

If you could also add the llvm.mem.parallel_loop_access metadata in the no-safelen case, that would be awesome! :-)

[alexey-bataev]

Committed revision 35083b6