[LLVMbugs] [Bug 19835] New: LICM::sink has exponential complexity on certain inputs

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19835

            Bug ID: 19835
           Summary: LICM::sink has exponential complexity on certain
                    inputs
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: eugeni.stepanov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat 1.cc
#define Q(i, j) b##j = a##j + x; a##i = a##j * b##j;
#define D(i) int a##i; int b##i;

int f(int x) {
  D(0)
  D(1)
  D(2)
  D(3)
  D(4)
  D(5)
  D(6)
  D(7)
  D(8)
  D(9)

  for (int i = 0; i < 100; ++i) {
    int volatile z = x;
    int a0 = z;
    Q(1, 0)
    Q(2, 1)
    Q(3, 2)
    Q(4, 3)
    Q(5, 4)
    Q(6, 5)
    Q(7, 6)
    Q(8, 7)
    Q(9, 8)
  }
  return a9;
}

$ ./bin/clang++ -S -emit-llvm -O1 1.cc -o - |& grep '%.*=' | wc -l
1027

Playing with the number of macro calls in the above source, I see that the
number of instructions in the IR is 2**(N+1) + 3.

IR itself contains lots of duplicate instructions:

define i32 @_Z1fi(i32 %x) #0 {
entry:
  %z = alloca i32, align 4
  br label %for.body

for.body:                                         ; preds = %for.body, %entry
  %i.033 = phi i32 [ 0, %entry ], [ %inc, %for.body ]
  store volatile i32 %x, i32* %z, align 4
  %z.0.z.0. = load volatile i32* %z, align 4
  %inc = add nsw i32 %i.033, 1
  %exitcond = icmp eq i32 %inc, 100
  br i1 %exitcond, label %for.end, label %for.body

for.end:                                          ; preds = %for.body
  %add.le1275 = add nsw i32 %z.0.z.0., %x
  %add.le1273 = add nsw i32 %z.0.z.0., %x
  %add.le1271 = add nsw i32 %z.0.z.0., %x
  %add.le1269 = add nsw i32 %z.0.z.0., %x
  %add.le1267 = add nsw i32 %z.0.z.0., %x
  %add.le1265 = add nsw i32 %z.0.z.0., %x
  %add.le1263 = add nsw i32 %z.0.z.0., %x
  %add.le1261 = add nsw i32 %z.0.z.0., %x
  %add.le1259 = add nsw i32 %z.0.z.0., %x
  %add.le1257 = add nsw i32 %z.0.z.0., %x
  %add.le1255 = add nsw i32 %z.0.z.0., %x
  %add.le1253 = add nsw i32 %z.0.z.0., %x
  %add.le1251 = add nsw i32 %z.0.z.0., %x
  %add.le1249 = add nsw i32 %z.0.z.0., %x
  %add.le1247 = add nsw i32 %z.0.z.0., %x
  %add.le1245 = add nsw i32 %z.0.z.0., %x
  %add.le1243 = add nsw i32 %z.0.z.0., %x
  %add.le1241 = add nsw i32 %z.0.z.0., %x
  %add.le1239 = add nsw i32 %z.0.z.0., %x
  %add.le1237 = add nsw i32 %z.0.z.0., %x
  %add.le1235 = add nsw i32 %z.0.z.0., %x
  %add.le1233 = add nsw i32 %z.0.z.0., %x
...
  %add.le = add nsw i32 %z.0.z.0., %x
  %mul.le1019 = mul nsw i32 %add.le, %z.0.z.0.
  %mul.le1016 = mul nsw i32 %add.le1023, %z.0.z.0.
  %mul.le1013 = mul nsw i32 %add.le1025, %z.0.z.0.
  %mul.le1010 = mul nsw i32 %add.le1027, %z.0.z.0.
  %mul.le1007 = mul nsw i32 %add.le1029, %z.0.z.0.
  %mul.le1004 = mul nsw i32 %add.le1031, %z.0.z.0.
  %mul.le1001 = mul nsw i32 %add.le1033, %z.0.z.0.
  %mul.le998 = mul nsw i32 %add.le1035, %z.0.z.0.
  %mul.le995 = mul nsw i32 %add.le1037, %z.0.z.0.
  %mul.le992 = mul nsw i32 %add.le1039, %z.0.z.0.
  %mul.le989 = mul nsw i32 %add.le1041, %z.0.z.0.
  %mul.le986 = mul nsw i32 %add.le1043, %z.0.z.0.
  %mul.le983 = mul nsw i32 %add.le1045, %z.0.z.0.
  %mul.le980 = mul nsw i32 %add.le1047, %z.0.z.0.
  %mul.le977 = mul nsw i32 %add.le1049, %z.0.z.0.
  %mul.le974 = mul nsw i32 %add.le1051, %z.0.z.0.
  %mul.le971 = mul nsw i32 %add.le1053, %z.0.z.0.
...


The problem is in LICM::sink, which does not handle the following pattern well:

f = op g
e = op f, g
d = op e
c = op d, e
b = op c
a = op b, c

When an instruction with N uses is sunk, each of its operands get N new uses
(all of them - phi nodes). In the example above, if a had 1 use, c would have
2, e would have 4, and g would have 8.

This has regressed in r201148:
http://llvm.org/viewvc/llvm-project?rev=201148&view=rev

-- 
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/20140523/2ca2194b/attachment.html>