[llvm-bugs] [Bug 28474] New: SLP Vectorizer does not correctly widen loads when vectorizing reductions

[via llvm-bugs]

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

            Bug ID: 28474
           Summary: SLP Vectorizer does not correctly widen loads when
                    vectorizing reductions
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: mkuper at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider:

void foo();

int test1(unsigned int *p) {
  int sum = 0;
  #pragma nounroll
  for (int y = 0; y < 2; y++) {
    // Inner loop gets unrolled
    for (int x = 0; x < 8; x++) {
      sum += p[x] * 42;
    }
    // Dummy call to keep outer loop alive
    foo();
  }
  return sum;
}

The body of the outer loop gets vectorized (see PR25748 for why the loop is so
odd-looking), but the loads and not properly widened, and we get:
  %0 = load i32, i32* %p, align 4, !tbaa !1
  %1 = load i32, i32* %arrayidx.1, align 4, !tbaa !1
  %2 = load i32, i32* %arrayidx.2, align 4, !tbaa !1
  %3 = load i32, i32* %arrayidx.3, align 4, !tbaa !1
  %4 = load i32, i32* %arrayidx.4, align 4, !tbaa !1
  %5 = load i32, i32* %arrayidx.5, align 4, !tbaa !1
  %6 = load i32, i32* %arrayidx.6, align 4, !tbaa !1
  %7 = load i32, i32* %arrayidx.7, align 4, !tbaa !1
  %8 = insertelement <8 x i32> undef, i32 %7, i32 0
  %9 = insertelement <8 x i32> %8, i32 %6, i32 1
  %10 = insertelement <8 x i32> %9, i32 %5, i32 2
  %11 = insertelement <8 x i32> %10, i32 %4, i32 3
  %12 = insertelement <8 x i32> %11, i32 %3, i32 4
  %13 = insertelement <8 x i32> %12, i32 %2, i32 5
  %14 = insertelement <8 x i32> %13, i32 %1, i32 6
  %15 = insertelement <8 x i32> %14, i32 %0, i32 7

This problem is specific to reductions, when building the tree from a store,
everything is fine. I think what's happening is that when vectorizing
reductions, the loads are collected in reverse order, so we don't notice they
are consecutive. But I still need to verify this.

-- 
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/20160708/32c6afa6/attachment.html>