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

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`.

Many Thanks,
Josh

On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com> wrote:
>
> > On Mar 19, 2015, at 9:43 AM, Josh Klontz <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         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/7128bb93/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_case.ll
Type: application/octet-stream
Size: 3976 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/7128bb93/attachment.obj>

> On Mar 19, 2015, at 10:18 AM, Josh Klontz <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/e7c53f6a/attachment.html>

Oh wow, good catch. Sorry for the noise!
-Josh

On Thu, Mar 19, 2015 at 2:56 PM, Adam Nemet <anemet at apple.com> wrote:
>
> On Mar 19, 2015, at 10:18 AM, Josh Klontz <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>
wrote:
>
>>
>> > On Mar 19, 2015, at 9:43 AM, Josh Klontz <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         http://llvm.cs.uiuc.edu
>> > 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/3ee3536c/attachment.html>