Closed
Description
; RUN: llc -mtriple=x86_64-- < %s
declare void @clobber()
define void @test(i1 %c, i64* %p, i64* noalias %p2) nounwind {
entry:
%val = load i64, i64* %p, align 8
br label %loop
loop:
switch i8 undef, label %unreachable [
i8 0, label %latch
i8 1, label %split.1
i8 2, label %split.2
i8 3, label %split.3
]
unreachable:
unreachable
split.3:
br i1 %c, label %clobber, label %sink
split.1:
br label %latch
split.2:
br label %latch
clobber:
call void @clobber()
br label %sink
sink:
store i64 %val, i64* %p2, align 8
br label %latch
latch:
%phi = phi i64 [ 0, %sink ], [ 0, %split.2 ], [ 1, %split.1 ], [ 0, %loop ]
%phi.live = add i64 %phi, 0
br label %loop
}
The load is sunk into split.3
, but may then be clobbered by following the split.3 -> clobber -> sink -> latch -> loop -> split.3 chain.
This is due to the functionality introduced in https://reviews.llvm.org/D86864, which uses incorrect post-dominance reasoning.