[llvm-bugs] [Bug 34171] New: Simple no-op loops with a termination flag are not optimized out

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Aug 12 09:35:56 PDT 2017


            Bug ID: 34171
           Summary: Simple no-op loops with a termination flag are not
                    optimized out
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: geoffrey at allott.email
                CC: llvm-bugs at lists.llvm.org

The following C code results in a loop with many iterations even with -O3; I
would expect it to be optimized out:


void do_nothing() {
    int i=200, q=0;
    while(!q) if (!--i) i=q=1;


; Function Attrs: norecurse nounwind readnone sspstrong uwtable
define void @do_nothing() local_unnamed_addr #0 {
  br label %1

; <label>:1:                                      ; preds = %1, %0
  %2 = phi i32 [ 200, %0 ], [ %3, %1 ]
  %3 = add nsw i32 %2, -25
  %4 = icmp eq i32 %3, 0
  br i1 %4, label %5, label %1

; <label>:5:                                      ; preds = %1
  ret void


    movl    $-200, %eax
    addl    $25, %eax
    jne .LBB0_1


(Any number low enough seems to optimize out - I assume because of some
hardcoded limits that simply evaluate some number of loops.)

It seems as though the problem is the fact that `i` is set to 1 on exit of the
loop - if this is removed then the loop is optimized away no matter the inital
value of i.

This situation can come up very often whenever a flag is used as the condition
to exit a loop. For instance, no-op loops in rust are not optimized out by llvm
because they terminate in such a way.

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/20170812/e3df5ab7/attachment.html>

More information about the llvm-bugs mailing list