40 lines · plain
1; RUN: opt -passes='loop(loop-rotate),print<access-info>' -S %s 2>&1 | FileCheck %s2; RUN: opt -passes='loop(loop-rotate),invalidate<loops>,print<access-info>' -S %s 2>&1 | FileCheck %s3 4; Make sure that the result of analysis is consistent regardless of blocks5; order as they are stored in loop. This test demonstrates the situation when6; recomputation of LI produces loop with different blocks order, and LA gives7; a different result for it. The reason of this bug hasn't been found yet, but8; the algorithm is somehow dependent on blocks order.9define void @test_01(ptr %p) {10; CHECK-LABEL: test_0111; CHECK: Report: unsafe dependent memory operations in loop.12; CHECK-NOT: Memory dependences are safe13entry:14 br label %loop15 16loop.progress: ; preds = %loop17 br label %loop.backedge18 19loop.backedge: ; preds = %loop.progress20 store i32 1, ptr %tmp7, align 421 %tmp = add nuw i64 %tmp5, 122 %tmp3 = icmp ult i64 %tmp, 100023 br i1 %tmp3, label %loop, label %exit24 25loop: ; preds = %loop.backedge, %entry26 %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 %tmp529 %tmp8 = load i32, ptr %tmp7, align 430 %tmp9 = add i32 %tmp8, -531 store i32 %tmp9, ptr %tmp7, align 432 br i1 false, label %never, label %loop.progress33 34never: ; preds = %loop35 unreachable36 37exit: ; preds = %loop.backedge38 ret void39}40