[LLVMbugs] [Bug 22179] New: SCEV incorrectly flags add recurrences as nsw

[bugzilla-daemon at llvm.org]

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

            Bug ID: 22179
           Summary: SCEV incorrectly flags add recurrences as nsw
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: sanjoy at playingwithpointers.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When running opt -analyze -scalar-evolution on the following program

%struct.anon = type { i8 }
%struct.S = type { i32 }

@a = common global %struct.anon zeroinitializer, align 1
@b = common global %struct.S zeroinitializer, align 4

; Function Attrs: nounwind ssp uwtable
define i32 @main() {
  store i8 0, i8* getelementptr inbounds (%struct.anon* @a, i64 0, i32 0),
align 1
  br label %loop

loop:
  %storemerge1 = phi i8 [ 0, %0 ], [ %inc, %loop ]
  %m = load volatile i32* getelementptr inbounds (%struct.S* @b, i64 0, i32 0),
align 4
  %inc = add nuw i8 %storemerge1, 1
  %exitcond = icmp eq i8 %inc, -128
  br i1 %exitcond, label %exit, label %loop

exit:
  store i8 -128, i8* getelementptr inbounds (%struct.anon* @a, i64 0, i32 0),
align 1
  ret i32 0
}


we get the SCEV {1,+,1}<nuw><nsw><%loop> for %inc = add nuw i8 %storemerge1, 1.
 However, the llvm expression can legitimately signed-overflow.

The real issue is that in several places in ScalarEvolution, we have

  // If FlagNSW is true and all the operands are non-negative, infer FlagNUW.
  // And vice-versa.


The vice-versa part is incorrect I think -- it is possible for {1,+,1} to not
unsigned-overflow, but it is okay for it to signed-overflow, for instance.

-- 
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/20150109/594b9aa5/attachment.html>