[llvm-bugs] [Bug 27632] New: SLP vectorizer is highly dependent on the operand order

via llvm-bugs llvm-bugs at lists.llvm.org
Tue May 3 17:28:57 PDT 2016


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

            Bug ID: 27632
           Summary: SLP vectorizer is highly dependent on the operand
                    order
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: googler, performance
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: danielcdh at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16302
  --> https://llvm.org/bugs/attachment.cgi?id=16302&action=edit
loads that cannot be vectorized

In the attached IR, the only difference between 1.ll and 2.ll is the order of
the add opeands, e.g.

33c33
<   %24 = add nsw i32 %23, %15
---
>   %24 = add nsw i32 %15, %23

However, this will lead to SLPVectorizer being unable to vectorize the basic
block.

#opt -slp-vectorizer 1.ll -S |grep load
  %9 = load i8, i8* %.08.i, align 1
  %10 = load i8, i8* %.036.i, align 1
  %12 = load i8, i8* %11, align 1
  %14 = load i8, i8* %13, align 1
  %16 = load i8, i8* %15, align 1
  %18 = load i8, i8* %17, align 1
  %20 = load i8, i8* %19, align 1
  %22 = load i8, i8* %21, align 1
  %24 = load i8, i8* %23, align 1
  %26 = load i8, i8* %25, align 1
  %28 = load i8, i8* %27, align 1
  %30 = load i8, i8* %29, align 1
  %32 = load i8, i8* %31, align 1
  %34 = load i8, i8* %33, align 1
  %36 = load i8, i8* %35, align 1
  %47 = load i8, i8* %46, align 1

#opt -slp-vectorizer x.ll -S |grep load
  %23 = load <8 x i8>, <8 x i8>* %22, align 1
  %27 = load <8 x i8>, <8 x i8>* %26, align 1

This is because when building the vectorization tree, it uses post-order to
traverse the reduction operations, and visits its children in the order of its
index. So if the index of the operand change, load will need to be processed in
reverse-order, thus cannot be vectorized.

Note that the operand could be any order after reassociation pass. Thus it
important that SLPVectorizer can handle any operand order.

-- 
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/20160504/667875de/attachment.html>


More information about the llvm-bugs mailing list