<div dir="ltr">Oh wow, good catch. Sorry for the noise!<div>-Josh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 2:56 PM, Adam Nemet <span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><span class=""><blockquote type="cite"><div>On Mar 19, 2015, at 10:18 AM, Josh Klontz <<a href="mailto:josh.klontz@gmail.com" target="_blank">josh.klontz@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Adam,<div><br></div><div>Please find the attached test case (run with ToT opt -O3). As you can see, `y_body` successfully is vectorized, though %33 and %46 are deemed MayAlias despite their exclusive use in loads ands stores marked with `llvm.mem.parallel_loop_access`.</div></div></div></blockquote><div><br></div></span><div>Looks like no bug here.  Your metadata is off.  As I understand the operand of llvm.mem.parallel_loop_access should reference a loop.  Your accesses use !1 but the loop is identified as !2.  Adjusting the loop like this removes the memchecks for me:</div><div><br></div><div><div>--- /tmp/test_case.ll   2015-03-19 11:52:52.000000000 -0700</div><div>+++ /tmp/test_case-2.ll 2015-03-19 11:53:00.000000000 -0700</div><div>@@ -84,7 +84,7 @@</div><div>   %x_increment = add nuw nsw i64 0, 1</div><div>   %y_increment = add nuw nsw i64 %y, 1</div><div>   %y_postcondition = icmp ne i64 %y_increment, %32</div><div>-  br i1 %y_postcondition, label %y_body, label %y_exit, !llvm.loop !2</div><div>+  br i1 %y_postcondition, label %y_body, label %y_exit, !llvm.loop !1</div><div><br></div><div> y_exit:                                           ; preds = %y_body</div><div>   ret %i16SXY* %18</div><div><br></div><div>Adam</div><div><br></div></div><br><blockquote type="cite"><div><span class=""><div dir="ltr"><div>Many Thanks,</div><div>Josh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Mar 19, 2015, at 9:43 AM, Josh Klontz <<a href="mailto:josh.klontz@gmail.com" target="_blank">josh.klontz@gmail.com</a>> wrote:<br>
><br>
> It seems that at some point in the not-so-distant-past that the loop vectorizer gained the ability to vectorize loops without explicit `llvm.loop` & `llvm.mem.parallel_loop_access` metadata. While that's awesome, there seems to be a regression in that `llvm.mem.parallel_loop_access` metadata doesn't make it into the alias analysis, and therefore a `vector.memcheck` basic block is inserted, where as before it was not.<br>
<br>
</span>There has been active development in this are to generalize LV’s dependence analysis and memcheck infrastructure.  The changes should not have affected functionality minus bugs.  If you have a testcase I can look at this.<br>
<br>
Adam<br>
<span><br>
> It's unclear if this is a regression, as I assume that if I upgrade my frontend to use the new alias metadata instead of the loop metadata then I would expect this problem to disappear. Please advise, happy to provide exemplar code if helpful.<br>
><br>
> v/r,<br>
> Josh<br>
</span>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</blockquote></div><br></div>
</span><span><test_case.ll></span></div></blockquote></div><br></div></blockquote></div><br></div>