On 05/23/2013 06:52 PM, Redmond, Paul wrote:> I'm not even sure you would need the llvm.loop.parallel anymore since the > vectorizer could just look to see if the loop id on a parallel_loop_access > matches the loop id of the loop being vectorized. > > Does this make any sense?Yes. However, I think you still need use the self-referencing metadata trick or similar to make the metadata identifying a loop unique, though (to avoid merging it with the metadata nodes with the same data). That is, e.g., the llvm.mem.parallel_loop_access has to refer to *the* original loop, not just any llvm.loop metadata with the same child metadata. On dropping the llvm.loop.parallel metadata and relying only on checking the parallel_loop_access to identify parallel loops, I'm not so sure. Does it retain all the info for all cases? Let's say you have a parallel loop without memory accesses but, say, a volatile inline asm block. In that case you do not have a way to communicate that the iterations in the said loop can be executed in any order if you cannot mark the loop itself parallel. Regards, -- --Pekka
On 2013-05-23, at 2:13 PM, Pekka Jääskeläinen wrote:> On 05/23/2013 06:52 PM, Redmond, Paul wrote: >> I'm not even sure you would need the llvm.loop.parallel anymore since the >> vectorizer could just look to see if the loop id on a parallel_loop_access >> matches the loop id of the loop being vectorized. >> >> Does this make any sense? > > Yes. However, I think you still need use the self-referencing > metadata trick or similar to make the metadata identifying a loop unique, > though (to avoid merging it with the metadata nodes with the same data). That > is, e.g., the llvm.mem.parallel_loop_access has to refer to *the* original > loop, not just any llvm.loop metadata with the same child metadata. > > On dropping the llvm.loop.parallel metadata and relying only on checking the parallel_loop_access to identify parallel loops, I'm not so sure. Does it > retain all the info for all cases? Let's say you have a parallel loop without > memory accesses but, say, a volatile inline asm block. In that case you do not > have a way to communicate that the iterations in the said loop can be executed in any order if you cannot mark the loop itself parallel. >In this case, can't you just add llvm.mem.parallel_loop_access to the "call void asm ..." Instruction in the IR? paul> Regards, > -- > --Pekka
On 2013-05-23, at 2:13 PM, Pekka Jääskeläinen wrote:> On 05/23/2013 06:52 PM, Redmond, Paul wrote: >> I'm not even sure you would need the llvm.loop.parallel anymore since the >> vectorizer could just look to see if the loop id on a parallel_loop_access >> matches the loop id of the loop being vectorized. >> >> Does this make any sense? > > Yes. However, I think you still need use the self-referencing > metadata trick or similar to make the metadata identifying a loop unique, > though (to avoid merging it with the metadata nodes with the same data). That > is, e.g., the llvm.mem.parallel_loop_access has to refer to *the* original > loop, not just any llvm.loop metadata with the same child metadata. >So it should look like: !0 = metadata !{ metadata !0, metadata !1, metadata !2 } !1 = metadata !{ metadata !"llvm.loop.parallel" } !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } Correct? paul> On dropping the llvm.loop.parallel metadata and relying only on checking the parallel_loop_access to identify parallel loops, I'm not so sure. Does it > retain all the info for all cases? Let's say you have a parallel loop without > memory accesses but, say, a volatile inline asm block. In that case you do not > have a way to communicate that the iterations in the said loop can be executed in any order if you cannot mark the loop itself parallel. > > Regards, > -- > --Pekka
On 05/23/2013 09:37 PM, Redmond, Paul wrote:> So it should look like: > > !0 = metadata !{ metadata !0, metadata !1, metadata !2 } > !1 = metadata !{ metadata !"llvm.loop.parallel" } > !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } > > Correct?Yep. And yes, I think one can just add the parallel_loop_access MD also to volatile inline asm calls and other instructions which might prevent parallelization. At least I do not quickly see a case that could break. -- --Pekka