[LLVMbugs] [Bug 11046] New: Loop unrolling should be driven by optimization opportunities

[bugzilla-daemon at llvm.org]

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

           Summary: Loop unrolling should be driven by optimization
                    opportunities
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This bug is split off from PR11034 to track a more general issue that can be
observed in the examples there. Consider:

% cat arr1.good.ll 
; ModuleID = 'arr1.cc'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

%struct.X = type { [25 x i8], [2 x i8] }

@_ZL2gx = internal unnamed_addr constant %struct.X { [25 x i8]
c"abcd\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00", [2 x
i8] c"a\00" }, align 1

define i32 @_Z5testXiiPc() nounwind uwtable readnone {
entry:
  br label %for.body

for.body:                                         ; preds = %for.body, %entry
  %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ]
  %sum.02 = phi i32 [ 0, %entry ], [ %add, %for.body ]
  %arrayidx = getelementptr inbounds %struct.X* @_ZL2gx, i64 0, i32 0, i64
%indvars.iv
  %0 = load i8* %arrayidx, align 1, !tbaa !0
  %conv = sext i8 %0 to i32
  %add = add nsw i32 %conv, %sum.02
  %indvars.iv.next = add i64 %indvars.iv, 1
  %lftr.wideiv = trunc i64 %indvars.iv.next to i32
  %exitcond = icmp eq i32 %lftr.wideiv, 21
  br i1 %exitcond, label %for.end, label %for.body

for.end:                                          ; preds = %for.body
  ret i32 %add
}

!0 = metadata !{metadata !"omnipotent char", metadata !1}
!1 = metadata !{metadata !"Simple C/C++ TBAA", null}

LLVM optimizes this with ease:
% ./bin/opt -S -O3 <arr1.good.ll
; ModuleID = '<stdin>'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

define i32 @_Z5testXiiPc() nounwind uwtable readnone {
entry:
  ret i32 394
}

But with a tiny diff:
% diff -u arr1.good.ll arr1.bad.ll 
--- arr1.good.ll        2011-09-30 23:22:45.795562851 -0700
+++ arr1.bad.ll 2011-09-30 23:22:52.846028642 -0700
@@ -19,7 +19,7 @@
   %add = add nsw i32 %conv, %sum.02
   %indvars.iv.next = add i64 %indvars.iv, 1
   %lftr.wideiv = trunc i64 %indvars.iv.next to i32
-  %exitcond = icmp eq i32 %lftr.wideiv, 21
+  %exitcond = icmp eq i32 %lftr.wideiv, 22
   br i1 %exitcond, label %for.end, label %for.body

 for.end:% diff -u arr1.good.ll arr1.bad.ll 

LLVM can't touch it, and it stays exactly the same.

>From PR11034, Andy said:
> Unrolling should be driven by identification of opportunities,
> not a context independent size threshold. I suggest you file another bug on
> that. I plan to close this one after making a minor fix to the hueristics.

So filed. =]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.