[PATCH] D120551: [SCEV] Enable verification in LoopPM
Nikita Popov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 25 03:38:40 PST 2022
nikic added a comment.
The pr35406.ll failure can be reduced to this:
define i32 @test() {
entry:
br label %loop1
loop1:
br i1 false, label %loop2, label %loop1.latch
loop2:
%iv = phi i32 [ 0, %loop1 ], [ %iv.next, %loop2 ]
%iv.next = add nuw nsw i32 %iv, 1
%cmp = icmp ne i32 %iv.next, 1
br i1 %cmp, label %loop1.latch, label %loop2
loop1.latch:
br label %loop1
}
; opt -indvars
define i32 @test() {
entry:
br label %loop1
loop1: ; preds = %loop1.latch, %entry
br i1 true, label %loop2.preheader, label %loop1.latch
loop2.preheader: ; preds = %loop1
br label %loop2
loop2: ; preds = %loop2.preheader, %loop2
br i1 true, label %loop1.latch.loopexit, label %loop2
loop1.latch.loopexit: ; preds = %loop2
br label %loop1.latch
loop1.latch: ; preds = %loop1.latch.loopexit, %loop1
br label %loop1
}
In this case the BECount of the inner loop legitimately changes from 1 to 0, and this isn't wrong, because the loop is unreachable.
We make use of the fact that the loop is unreachable due to https://github.com/llvm/llvm-project/blob/20a093e2bc310283ec216ab47fddb68f0bdaa6f0/llvm/lib/Analysis/ScalarEvolution.cpp#L11024-L11027, introduced in D98706 <https://reviews.llvm.org/D98706>. And apparently this is already a known issue, with a variant reported in: https://github.com/llvm/llvm-project/issues/50523
I'm not really sure what to do about that. I think the options are a) give up on BECount verification entirely, b) drop that isImpliedCond() change, as I think it is of very limited practical value (the next SimplifyCFG will eliminate that code entirely, so it is irrelevant how we optimize it) or c) try to limit BECount verification to loops that are reachable, while taking into account constant branches.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D120551/new/
https://reviews.llvm.org/D120551
More information about the llvm-commits
mailing list