[polly] r278738 - [ScopDetect] Do not assert in case of AddRecs with non-constant start expression

[Tobias Grosser via llvm-commits]

Author: grosser
Date: Mon Aug 15 15:59:30 2016
New Revision: 278738

URL: http://llvm.org/viewvc/llvm-project?rev=278738&view=rev
Log:
[ScopDetect] Do not assert in case of AddRecs with non-constant start expression

Added:
    polly/trunk/test/ScopDetect/non-constant-add-rec-start-expr.ll
Modified:
    polly/trunk/lib/Support/SCEVValidator.cpp

Modified: polly/trunk/lib/Support/SCEVValidator.cpp
URL: http://llvm.org/viewvc/llvm-project/polly/trunk/lib/Support/SCEVValidator.cpp?rev=278738&r1=278737&r2=278738&view=diff
==============================================================================
--- polly/trunk/lib/Support/SCEVValidator.cpp (original)
+++ polly/trunk/lib/Support/SCEVValidator.cpp Mon Aug 15 15:59:30 2016
@@ -232,8 +232,7 @@ public:
       return ValidatorResult(SCEVType::INVALID);
     }
 
-    assert(Start.isConstant() && Recurrence.isConstant() &&
-           "Expected 'Start' and 'Recurrence' to be constant");
+    assert(Recurrence.isConstant() && "Expected 'Recurrence' to be constant");
 
     // Directly generate ValidatorResult for Expr if 'start' is zero.
     if (Expr->getStart()->isZero())

Added: polly/trunk/test/ScopDetect/non-constant-add-rec-start-expr.ll
URL: http://llvm.org/viewvc/llvm-project/polly/trunk/test/ScopDetect/non-constant-add-rec-start-expr.ll?rev=278738&view=auto
==============================================================================
--- polly/trunk/test/ScopDetect/non-constant-add-rec-start-expr.ll (added)
+++ polly/trunk/test/ScopDetect/non-constant-add-rec-start-expr.ll Mon Aug 15 15:59:30 2016
@@ -0,0 +1,50 @@
+; RUN: opt %loadPolly -polly-detect -\
+; RUN:     -analyze < %s | FileCheck %s
+
+; CHECK: Valid Region for Scop: bb11 => bb25
+
+; Ensure that this test case does not trigger an assertion. At some point,
+; we asserted on scops containing accesses where the access function contained
+; an AddRec expression with a non-constant step expression. This got missed, as
+; this very specific pattern does not seem too common. Even in this test case,
+; it disappears as soon as we turn the infinite loop into a finite loop.
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define void @hoge() local_unnamed_addr {
+bb:
+  %tmp = alloca [18 x [16 x i32]]
+  %tmp1 = alloca [17 x i32]
+  br label %bb2
+
+bb2:
+  %tmp3 = phi i64 [ 0, %bb ], [ %tmp5, %bb2 ]
+  %tmp4 = add nuw nsw i64 %tmp3, 2
+  %tmp5 = add nuw nsw i64 %tmp3, 1
+  br i1 undef, label %bb2, label %bb11
+
+bb11:
+  %tmp12 = phi i64 [ %tmp23, %bb24 ], [ 1, %bb2 ]
+  %tmp14 = getelementptr inbounds [17 x i32], [17 x i32]* %tmp1, i64 0, i64 1
+  br label %bb15
+
+bb15:
+  %tmp16 = sub nsw i64 %tmp12, 1
+  %tmp17 = shl i64 %tmp16, 32
+  %tmp18 = ashr exact i64 %tmp17, 32
+  %tmp19 = getelementptr inbounds [18 x [16 x i32]], [18 x [16 x i32]]* %tmp, i64 0, i64 %tmp4, i64 %tmp18
+  %tmp20 = load i32, i32* %tmp19, align 4
+  store i32 4, i32* %tmp19
+  br label %bb21
+
+bb21:
+  %tmp23 = add nuw nsw i64 %tmp12, 1
+  br i1 true, label %bb24, label %bb25
+
+bb24:
+  br label %bb11
+
+bb25:
+  ret void
+}