[LLVMdev] [LV] possible `vector.memcheck` regression when using `llvm.loop` and `llvm.mem.parallel_loop_access`

[Adam Nemet]

> On Mar 19, 2015, at 2:05 PM, Josh Klontz <josh.klontz at gmail.com> wrote:
> 
> Oh wow, good catch. Sorry for the noise!

No problem.

> -Josh
> 
> On Thu, Mar 19, 2015 at 2:56 PM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote:
> 
>> On Mar 19, 2015, at 10:18 AM, Josh Klontz <josh.klontz at gmail.com <mailto:josh.klontz at gmail.com>> wrote:
>> 
>> Adam,
>> 
>> 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`.
> 
> 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:
> 
> --- /tmp/test_case.ll   2015-03-19 11:52:52.000000000 -0700
> +++ /tmp/test_case-2.ll 2015-03-19 11:53:00.000000000 -0700
> @@ -84,7 +84,7 @@
>    %x_increment = add nuw nsw i64 0, 1
>    %y_increment = add nuw nsw i64 %y, 1
>    %y_postcondition = icmp ne i64 %y_increment, %32
> -  br i1 %y_postcondition, label %y_body, label %y_exit, !llvm.loop !2
> +  br i1 %y_postcondition, label %y_body, label %y_exit, !llvm.loop !1
> 
>  y_exit:                                           ; preds = %y_body
>    ret %i16SXY* %18
> 
> Adam
> 
> 
>> Many Thanks,
>> Josh
>> 
>> On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote:
>> 
>> > On Mar 19, 2015, at 9:43 AM, Josh Klontz <josh.klontz at gmail.com <mailto:josh.klontz at gmail.com>> wrote:
>> >
>> > 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.
>> 
>> 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.
>> 
>> Adam
>> 
>> > 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.
>> >
>> > v/r,
>> > Josh
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> 
>> 
>> <test_case.ll>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/e57fee26/attachment.html>