[llvm-bugs] [Bug 32694] New: Loop Access Analysis missing an analyzable stride?

[via llvm-bugs]

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

            Bug ID: 32694
           Summary: Loop Access Analysis missing an analyzable stride?
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18300
  --> https://bugs.llvm.org/attachment.cgi?id=18300&action=edit
reduced test case with loop that gives 16 scalarized adjacent stores

The loop vectorizer is looking at this loop:

for.body617:                                      ; preds =
%for.body617.preheader, %for.body617
  %indvars.iv = phi i64 [ %1, %for.body617.preheader ], [ %indvars.iv.next,
%for.body617 ]
  %2 = load i8*, i8** @stack_usage_map, align 8, !tbaa !1
  %arrayidx619 = getelementptr inbounds i8, i8* %2, i64 %indvars.iv
  store i8 1, i8* %arrayidx619, align 1, !tbaa !5
  %indvars.iv.next = add nsw i64 %indvars.iv, 1
  %cmp615 = icmp slt i64 %indvars.iv, -1
  br i1 %cmp615, label %for.body617, label %for.cond496.loopexit

LAI does not see that the store i8 is adding the IV to a loop invariant base
register. It seems to think that the %2 is a loop varying register:

LAA: Bad stride - Not an AddRecExpr pointer   %arrayidx619 = getelementptr
inbounds i8, i8* %2, i64 %indvars.iv SCEV: ({(sext i32 %i.0.ph to i64),+
,1}<nsw><%for.body617> + %2)<nsw>

%2 is actually a loop invariant load of a pointer, and I am wondering if this
is a deficiency that could be fixed? If not, I am curious why this is not safe?

The attached file was reduced automatically, and I hope it serves the purpose
for demonstration.

bin/opt -mtriple=s390x-unknown-linux -mcpu=z13 -O3 ./stores_16i8.ll -o
./out.opt.ll -S

The vectorizer output is 16 scalarized stores adjacent stores (which in this
case the backend manages to combine luckily...)

vector.body:                                      ; preds =
%vector.body.preheader, %vector.body
  %index = phi i64 [ %index.next, %vector.body ], [ 0, %vector.body.preheader ]
  %offset.idx = add i64 %index, %3
  %7 = add i64 %index, %3
  %8 = add i64 %offset.idx, 1
  %9 = add i64 %offset.idx, 2
  %10 = add i64 %offset.idx, 3
  %11 = add i64 %offset.idx, 4
  %12 = add i64 %offset.idx, 5
  %13 = add i64 %offset.idx, 6
  %14 = add i64 %offset.idx, 7
  %15 = add i64 %offset.idx, 8
  %16 = add i64 %offset.idx, 9
  %17 = add i64 %offset.idx, 10
  %18 = add i64 %offset.idx, 11
  %19 = add i64 %offset.idx, 12
  %20 = add i64 %offset.idx, 13
  %21 = add i64 %offset.idx, 14
  %22 = add i64 %offset.idx, 15
  %23 = getelementptr inbounds i8, i8* %0, i64 %7
  %24 = getelementptr inbounds i8, i8* %0, i64 %8
  %25 = getelementptr inbounds i8, i8* %0, i64 %9
  %26 = getelementptr inbounds i8, i8* %0, i64 %10
  %27 = getelementptr inbounds i8, i8* %0, i64 %11
  %28 = getelementptr inbounds i8, i8* %0, i64 %12
  %29 = getelementptr inbounds i8, i8* %0, i64 %13
  %30 = getelementptr inbounds i8, i8* %0, i64 %14
  %31 = getelementptr inbounds i8, i8* %0, i64 %15
  %32 = getelementptr inbounds i8, i8* %0, i64 %16
  %33 = getelementptr inbounds i8, i8* %0, i64 %17
  %34 = getelementptr inbounds i8, i8* %0, i64 %18
  %35 = getelementptr inbounds i8, i8* %0, i64 %19
  %36 = getelementptr inbounds i8, i8* %0, i64 %20
  %37 = getelementptr inbounds i8, i8* %0, i64 %21
  %38 = getelementptr inbounds i8, i8* %0, i64 %22
  store i8 1, i8* %23, align 1, !tbaa !5
  store i8 1, i8* %24, align 1, !tbaa !5
  store i8 1, i8* %25, align 1, !tbaa !5
  store i8 1, i8* %26, align 1, !tbaa !5
  store i8 1, i8* %27, align 1, !tbaa !5
  store i8 1, i8* %28, align 1, !tbaa !5
  store i8 1, i8* %29, align 1, !tbaa !5
  store i8 1, i8* %30, align 1, !tbaa !5
  store i8 1, i8* %31, align 1, !tbaa !5
  store i8 1, i8* %32, align 1, !tbaa !5
  store i8 1, i8* %33, align 1, !tbaa !5
  store i8 1, i8* %34, align 1, !tbaa !5
  store i8 1, i8* %35, align 1, !tbaa !5
  store i8 1, i8* %36, align 1, !tbaa !5
  store i8 1, i8* %37, align 1, !tbaa !5
  store i8 1, i8* %38, align 1, !tbaa !5
  %index.next = add i64 %index, 16
  %39 = icmp eq i64 %index.next, %n.vec
  br i1 %39, label %middle.block, label %vector.body, !llvm.loop !6

-- 
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/20170418/dbfec112/attachment-0001.html>