llvm/test/Analysis/LoopAccessAnalysis/pr56672.ll

   1 ; RUN: opt -passes='loop(loop-rotate),print-access-info' -S %s 2>&1 | FileCheck %s
   2 ; RUN: opt -passes='loop(loop-rotate),invalidate<loops>,print-access-info' -S %s 2>&1 | FileCheck %s
   3
   4 ; Make sure that the result of analysis is consistent regardless of blocks
   5 ; order as they are stored in loop. This test demonstrates the situation when
   6 ; recomputation of LI produces loop with different blocks order, and LA gives
   7 ; a different result for it. The reason of this bug hasn't been found yet, but
   8 ; the algorithm is somehow dependent on blocks order.
   9 define void @test_01(i32* %p) {
  10 ; CHECK-LABEL: test_01
  11 ; CHECK:       Report: unsafe dependent memory operations in loop.
  12 ; CHECK-NOT:   Memory dependences are safe
  13 entry:
  14   br label %loop
  15
  16 loop.progress:                                              ; preds = %loop
  17   br label %loop.backedge
  18
  19 loop.backedge:                                              ; preds = %loop.progress
  20   store i32 1, i32* %tmp7, align 4
  21   %tmp = add nuw i64 %tmp5, 1
  22   %tmp3 = icmp ult i64 %tmp, 1000
  23   br i1 %tmp3, label %loop, label %exit
  24
  25 loop:                                              ; preds = %loop.backedge, %entry
  26   %tmp5 = phi i64 [ %tmp, %loop.backedge ], [ 16, %entry ]
  27   %tmp6 = phi i64 [ %tmp5, %loop.backedge ], [ 15, %entry ]
  28   %tmp7 = getelementptr inbounds i32, i32* %p, i64 %tmp5
  29   %tmp8 = load i32, i32* %tmp7, align 4
  30   %tmp9 = add i32 %tmp8, -5
  31   store i32 %tmp9, i32* %tmp7, align 4
  32   br i1 false, label %never, label %loop.progress
  33
  34 never:                                             ; preds = %loop
  35   unreachable
  36
  37 exit:                                             ; preds = %loop.backedge
  38   ret void
  39 }