[llvm-dev] LLVM's loop unroller & llvm.loop.parallel_accesses (original) (raw)

Hendrik Greving via llvm-dev llvm-dev at lists.llvm.org
Thu May 14 14:16:26 PDT 2020

This is interesting! So are you saying that loop.parallel_accesses strictly loop parallel, and says nothing about aliasing? I see, I guess we may have been "abusing" the hint and re-purposed it. But isn't llvm's vectorizer using loop.parallel_accesses to vectorize loops including vectorize memory accesses that if you ignore loop-carried dependencies, usually means effectively re-ordering the accesses? I guess this still does not imply "noalias"? What about icc/gcc's #pragma ivdep? Again here, it means no loop-carried dependencies, yet still doesn't say anything about noalias? Another way indeed would be to propagate noalias data and indeed rely on the future fix that Hal mentions above.

On Thu, May 14, 2020 at 1:33 PM Michael Kruse <llvmdev at meinersbur.de> wrote:

llvm.loop.parallelaccesses does not imply that these accesses from different iterations are not aliasing. Examples where an access are parallel are that the accesses are atomic or read-only from a specific location.

The LoopUnrollPass might deduce that non-atomic stores are necessarily not aliasing (when not using transactional memory), but I don't think we can do this for all the read accesses. Would that be sufficiently useful? Michael

Am Do., 14. Mai 2020 um 15:11 Uhr schrieb Hendrik Greving via llvm-dev <llvm-dev at lists.llvm.org>: > > Hi, in our backend, which is unfortunately not upstreamed, we are relying on llvm.loop.parallelaccesses metadata for certain passes like software pipelining so we can re-order instructions. Ideally, we would want the loop unroller to support the notion of the loop's parallelism in its pre-unrolled version. This probably should happen by propagating !alias.scope and !alias metadata. Is there any plan or open patch for supporting this? > > Simplified example: > > for.body: > %0 = load [..] > store %0 [..] > br label %for.cond, !llvm.loop !2 > > !1 = distinct !{} > !2 = distinct !{!2, !3, !4, !5, !6, !7} > !3 = !{!"llvm.loop.parallelaccesses", !1} > !4 = !{!"llvm.loop.vectorize.width", i32 1} > !5 = !{!"llvm.loop.interleave.count", i32 1} > !6 = !{!"llvm.loop.vectorize.enable", i1 true} > !7 = !{!"llvm.loop.vectorize.followupall", !8} > !8 = !{!"llvm.loop.unroll.count", i32 2} > > (unroll by 2) => > > for.body: > %0 = load [..] !alias.scope !9 !noalias !11 > store %0 [..] !alias.scope !9 !noalias !11 > %1 = load [..] !alias.scope !10 !noalias !12 > store %1 [..] !alias.scope !10 !noalias !12 > br label %for.cond, !llvm.loop !2 > > [..] > > !9 = distinct !{!9, !"iteration0"} > !10 = distinct !{!10, !"iteration1"} > !11 = !{!10} > !12 = !{!9} > > Thanks, Hendrik _> ________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200514/3deb8541/attachment.html>

More information about the llvm-dev mailing list