1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 03:02:36 +01:00
llvm-mirror/test/Analysis/ScalarEvolution/max-be-count-not-constant.ll
Sanjoy Das f1309f7dda [SCEV] Fix an assertion failure in the max backedge taken count
Max backedge taken count is always expected to be a constant; and this is
usually true by construction -- it is a SCEV expression with constant inputs.
However, if the max backedge expression ends up being computed to be a udiv with
a constant zero denominator[0], SCEV does not fold the result to a constant
since there is no constant it can fold it to (SCEV has no representation for
"infinity" or "undef").

However, in computeMaxBECountForLT we already know the denominator is positive,
and thus at least 1; and we can use this fact to avoid dividing by zero.

[0]: We can end up with a constant zero denominator if the signed range of the
stride is more precise than the unsigned range.

llvm-svn: 316615
2017-10-25 21:41:00 +00:00

27 lines
856 B
LLVM

; RUN: opt < %s -analyze -scalar-evolution | FileCheck %s
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Previously in this case the max backedge count would be computed as 1/0, which
; is correct but undesirable. It would also not fold as a constant, tripping
; asserts in SCEV.
define void @pluto(i32 %arg) {
; CHECK-LABEL: Classifying expressions for: @pluto
; CHECK: Loop %bb2: max backedge-taken count is 2
bb:
%tmp = ashr i32 %arg, 31
%tmp1 = add nsw i32 %tmp, 2
br label %bb2
bb2: ; preds = %bb2, %bb
%tmp3 = phi i32 [ 0, %bb ], [ %tmp4, %bb2 ]
%tmp4 = add nuw nsw i32 %tmp1, %tmp3
%tmp5 = icmp ult i32 %tmp4, 2
br i1 %tmp5, label %bb2, label %bb6
bb6: ; preds = %bb2
ret void
}