<div dir="ltr">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.<div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 14, 2020 at 1:33 PM Michael Kruse <<a href="mailto:llvmdev@meinersbur.de">llvmdev@meinersbur.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">llvm.loop.parallel_accesses does not imply that these accesses from<br>
different iterations are not aliasing. Examples where an access are<br>
parallel are that the accesses are atomic or read-only from a specific<br>
location.<br>
<br>
The LoopUnrollPass might deduce that non-atomic stores are necessarily<br>
not aliasing (when not using transactional memory), but I don't think<br>
we can do this for all the read accesses. Would that be sufficiently<br>
useful?<br>
<br>
Michael<br>
<br>
<br>
Am Do., 14. Mai 2020 um 15:11 Uhr schrieb Hendrik Greving via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>:<br>
><br>
> Hi, in our backend, which is unfortunately not upstreamed, we are relying on llvm.loop.parallel_accesses 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?<br>
><br>
> Simplified example:<br>
><br>
> for.body:<br>
> %0 = load [..]<br>
>  store %0 [..]<br>
> br label %for.cond, !llvm.loop !2<br>
><br>
> !1 = distinct !{}<br>
> !2 = distinct !{!2, !3, !4, !5, !6, !7}<br>
> !3 = !{!"llvm.loop.parallel_accesses", !1}<br>
> !4 = !{!"llvm.loop.vectorize.width", i32 1}<br>
> !5 = !{!"llvm.loop.interleave.count", i32 1}<br>
> !6 = !{!"llvm.loop.vectorize.enable", i1 true}<br>
> !7 = !{!"llvm.loop.vectorize.followup_all", !8}<br>
> !8 = !{!"llvm.loop.unroll.count", i32 2}<br>
><br>
> (unroll by 2) =><br>
><br>
> for.body:<br>
> %0 = load [..] !alias.scope !9 !noalias !11<br>
> store %0 [..] !alias.scope !9 !noalias !11<br>
> %1 = load [..] !alias.scope !10 !noalias !12<br>
>  store %1 [..] !alias.scope !10 !noalias !12<br>
> br label %for.cond, !llvm.loop !2<br>
><br>
> [..]<br>
><br>
> !9 = distinct !{!9, !"iteration0"}<br>
> !10 = distinct !{!10, !"iteration1"}<br>
> !11 = !{!10}<br>
> !12 = !{!9}<br>
><br>
> Thanks, Hendrik<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>