[LLVMbugs] [Bug 23997] New: LoopVectorizer dropping inbounds from GEPs

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=23997

            Bug ID: 23997
           Summary: LoopVectorizer dropping inbounds from GEPs
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I've noticed that the LoopVectorizer seems to not mark the GEPs it generates as
inbounds, even when the original GEPs being replaced are in bounds.  

Specifically, this can be reproduced with just about any vectorizable loop
which contains either a load or store to a loop variant location derived from a
pointer typed induction variable.  Consider:

define void @test2(i8* %base, i8* %end) {
entry:
  br label %loop
loop:
  %p = phi i8* [%base, %entry], [%next, %loop]
  store i8 0, i8* %p
  %next = getelementptr inbounds i8, i8* %p, i64 1
  %cmp = icmp slt i8* %p, %end
  br i1 %cmp, label %loop, label %exit
exit:
  ret void
}

The generated code for vector.body is:
vector.body
  %index = phi i64 [ %index.next, %vector.body ], [ 0, %overflow.checked ]
  %next.gep = getelementptr i8, i8* %base, i64 %index ;;<-- KEY LINE
  %4 = bitcast i8* %next.gep to <4 x i8>*
  store <4 x i8> zeroinitializer, <4 x i8>* %4, align 1
  %index.next = add i64 %index, 4
  %5 = icmp eq i64 %index.next, %n.vec
  br i1 %5, label %middle.block, label %vector.body, !llvm.loop !5

Interestingly, using a integer induction variable for this loop and then
deriving p off of that on every iteration does end up with the new phis having
inbounds.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150630/90d2aa2a/attachment.html>