Fix ScalarEvolution's backedge-taken count computations to check for

overflow when computing a integer division to round up.

Thanks to Nick Lewycky for noticing this!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73862 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Dan Gohman
2009-06-21 23:46:38 +00:00
parent 14ee48a5ba
commit 51f53b7f5a
5 changed files with 51 additions and 11 deletions

View File

@@ -1,4 +1,9 @@
; RUN: llvm-as < %s | opt -analyze -scalar-evolution -disable-output |& grep {/u 3}
; RUN: llvm-as < %s | opt -analyze -scalar-evolution -disable-output \
; RUN: | grep {Loop bb: Unpredictable backedge-taken count\\.}
; ScalarEvolution can't compute a trip count because it doesn't know if
; dividing by the stride will have a remainder. This could theoretically
; be teaching it how to use a more elaborate trip count computation.
define i32 @f(i32 %x) nounwind readnone {
entry:

View File

@@ -1,5 +1,9 @@
; RUN: llvm-as < %s | opt -scalar-evolution -analyze -disable-output \
; RUN: | grep {backedge-taken count is ((64 + (-64 smax (-1 + (-1 \\* %0))) + %0) /u 64)}
; RUN: | grep {Loop bb3\\.i: Unpredictable backedge-taken count\\.}
; ScalarEvolution can't compute a trip count because it doesn't know if
; dividing by the stride will have a remainder. This could theoretically
; be teaching it how to use a more elaborate trip count computation.
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-unknown-linux-gnu"