555e09c2b0
This updates the naming for the LAA printing pass to be in line with most other analysis printing passes. The old name has come up as confusing multiple times already, e.g. in D131924.
40 lines
1.6 KiB
LLVM
40 lines
1.6 KiB
LLVM
; RUN: opt -passes='loop(loop-rotate),print<access-info>' -S %s 2>&1 | FileCheck %s
|
|
; RUN: opt -passes='loop(loop-rotate),invalidate<loops>,print<access-info>' -S %s 2>&1 | FileCheck %s
|
|
|
|
; Make sure that the result of analysis is consistent regardless of blocks
|
|
; order as they are stored in loop. This test demonstrates the situation when
|
|
; recomputation of LI produces loop with different blocks order, and LA gives
|
|
; a different result for it. The reason of this bug hasn't been found yet, but
|
|
; the algorithm is somehow dependent on blocks order.
|
|
define void @test_01(i32* %p) {
|
|
; CHECK-LABEL: test_01
|
|
; CHECK: Report: unsafe dependent memory operations in loop.
|
|
; CHECK-NOT: Memory dependences are safe
|
|
entry:
|
|
br label %loop
|
|
|
|
loop.progress: ; preds = %loop
|
|
br label %loop.backedge
|
|
|
|
loop.backedge: ; preds = %loop.progress
|
|
store i32 1, i32* %tmp7, align 4
|
|
%tmp = add nuw i64 %tmp5, 1
|
|
%tmp3 = icmp ult i64 %tmp, 1000
|
|
br i1 %tmp3, label %loop, label %exit
|
|
|
|
loop: ; preds = %loop.backedge, %entry
|
|
%tmp5 = phi i64 [ %tmp, %loop.backedge ], [ 16, %entry ]
|
|
%tmp6 = phi i64 [ %tmp5, %loop.backedge ], [ 15, %entry ]
|
|
%tmp7 = getelementptr inbounds i32, i32* %p, i64 %tmp5
|
|
%tmp8 = load i32, i32* %tmp7, align 4
|
|
%tmp9 = add i32 %tmp8, -5
|
|
store i32 %tmp9, i32* %tmp7, align 4
|
|
br i1 false, label %never, label %loop.progress
|
|
|
|
never: ; preds = %loop
|
|
unreachable
|
|
|
|
exit: ; preds = %loop.backedge
|
|
ret void
|
|
}
|