[LLVMbugs] [Bug 8041] New: licm miscompile - wrongly thinks value is loop invariant

[bugzilla-daemon at llvm.org]

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

           Summary: licm miscompile - wrongly thinks value is loop
                    invariant
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5433)
 --> (http://llvm.org/bugs/attachment.cgi?id=5433)
testcase .ll

When the attached testcase is compiled using "opt -licm", the original program
(from SPEC) goes into an infinite loop.  This is because licm thinks the exit
condition for one of the loops is loop invariant, but it isn't.  Here is a
snippet with comments (from the unoptimized code, see attachment):

bb6:                                              ; preds = %eshup8.exit, %bb4
  %tmp60 = load i16** %p, align 8                 ; <i16*> [#uses=1]
; %p is loop invariant, but what it points to is not loop invariant
  %tmp61 = load i16* %tmp60, align 2              ; <i16> [#uses=1]
; thus %tmp61 is not loop invariant
  %tmp62 = zext i16 %tmp61 to i32                 ; <i32> [#uses=1]
  %tmp63 = and i32 %tmp62, 65280                  ; <i32> [#uses=1]
  %tmp64 = icmp eq i32 %tmp63, 0                  ; <i1> [#uses=1]
; licm wrongly thinks that %tmp64 is loop invariant, and hoists it, causing an
infinite loop
  br i1 %tmp64, label %bb5, label %bb9

The function has a parameter i16* %x, which is a pointer to an array of i16,
and %p is an offset from %x, i.e. it also points into the array.

The loop goes bb5 -> bb1.i6 -> bb.i5 -> bb1.i6 (whizzes around between
bb.i5 and bb1.i6 for a while) -> eshup8.exit -> bb6 -> bb5 (if the exit
condition is not satisfied).  In the loop the variable %x_addr.i3 is a
handle to an array element; it visits all array elements in the subloop,
which is a reverse traversal over the array elements.  The subloop modifies
the array element which *%x_addr.i3 is currently pointing to.

Thus it is clear that while %p itself is loop invariant, it is pointing
to memory (the array) that gets modified in the loop.  Thus licm is wrong
to think that the value loaded from %p is loop invariant.

-- 
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.