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. 9define void @test_01(ptr %p) { 10; CHECK-LABEL: test_01 11; CHECK: Report: unsafe dependent memory operations in loop. 12; CHECK-NOT: Memory dependences are safe 13entry: 14 br label %loop 15 16loop.progress: ; preds = %loop 17 br label %loop.backedge 18 19loop.backedge: ; preds = %loop.progress 20 store i32 1, ptr %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 25loop: ; 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, ptr %p, i64 %tmp5 29 %tmp8 = load i32, ptr %tmp7, align 4 30 %tmp9 = add i32 %tmp8, -5 31 store i32 %tmp9, ptr %tmp7, align 4 32 br i1 false, label %never, label %loop.progress 33 34never: ; preds = %loop 35 unreachable 36 37exit: ; preds = %loop.backedge 38 ret void 39} 40