[LLVMbugs] [Bug 24078] New: LICM incorrectly hoists load

[bugzilla-daemon at llvm.org]

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

            Bug ID: 24078
           Summary: LICM incorrectly hoists load
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: sanjoy at playingwithpointers.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Running opt -licm on

define i32 @x(i32* %x, i1* %y) {
 entry:
  br label %loop

 loop:
  %v = phi i32 [ 0 , %entry ], [ %v.inc, %exit.inner ], [ %v, %loop ]
  %c = load volatile i1, i1* %y
  br i1 %c, label %exit.inner, label %loop

 exit.inner:
  %c1 = load volatile i1, i1* %y
  %x.val = load i32, i32* %x
  %v.inc = add i32 %v, %x.val
  br i1 %c1, label %exit.real, label %loop

 exit.real:
  ret i32 %v
}

results in

; ModuleID = '/Users/sanjoy/tmp/inf.ll'

define i32 @x(i32* %x, i1* %y) {
entry:
  %x.val = load i32, i32* %x
  br label %loop.outer

loop.outer:                                       ; preds = %exit.inner, %entry
  %v.ph = phi i32 [ %v.inc, %exit.inner ], [ 0, %entry ]
  br label %loop

loop:                                             ; preds = %loop.outer, %loop
  %c = load volatile i1, i1* %y
  br i1 %c, label %exit.inner, label %loop

exit.inner:                                       ; preds = %loop
  %c1 = load volatile i1, i1* %y
  %v.inc = add i32 %v.ph, %x.val
  br i1 %c1, label %exit.real, label %loop.outer

exit.real:                                        ; preds = %exit.inner
  %v.ph.lcssa = phi i32 [ %v.ph, %exit.inner ]
  ret i32 %v.ph.lcssa
}

For an non-dereferenceable %x, the original program is well defined if
%c is always false.  But the new program unconditionally dereferences
%x, effectively introducing UB if %x is not dereferenceable.

The bug is in isGuaranteedToExecute.  It assumes that if an
instruction dominates all the loop exits then it will always be
executed by the loop "on its way out".  But there may never be a way
out of the loop.

-- 
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/20150709/ad89e0e6/attachment.html>