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

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/90facd55/attachment.html>

> 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

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>