<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 10:18 AM, Josh Klontz <<a href="mailto:josh.klontz@gmail.com" class="">josh.klontz@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Adam,<div class=""><br class=""></div><div class="">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 class=""></div><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 class=""></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 class=""></div><div> y_exit:                                           ; preds = %y_body</div><div>   ret %i16SXY* %18</div><div><br class=""></div><div>Adam</div><div><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Many Thanks,</div><div class="">Josh</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <span dir="ltr" class=""><<a href="mailto:anemet@apple.com" target="_blank" class="">anemet@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On Mar 19, 2015, at 9:43 AM, Josh Klontz <<a href="mailto:josh.klontz@gmail.com" class="">josh.klontz@gmail.com</a>> wrote:<br class="">
><br class="">
> 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 class="">
<br class="">
</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 class="">
<br class="">
Adam<br class="">
<span class=""><br class="">
> 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 class="">
><br class="">
> v/r,<br class="">
> Josh<br class="">
</span>> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class="">
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class="">
<br class="">
</blockquote></div><br class=""></div>
<span id="cid:5FA81C9C-C92F-48F8-8EED-85B7BCE0E2B5@apple.com"><test_case.ll></span></div></blockquote></div><br class=""></body></html>