Previously in function getExpectedExitLoopLatchBranch we considered a block deoptimizing if it had a terminating deoptimize call.
Now updated to it to keep in sync with almost the same logic in LoopPeel (see https://reviews.llvm.org/D110922).
From that patch:
Added support for peeling loops with "deoptimizing" exits - such exits that it or any of its children (or any of their children, etc) either has a @llvm.experimental.deoptimize call
prior to the terminating return instruction of this basic block or is terminated with unreachable. All blocks in the the sequence must have a single successor, maybe except for the > last one.
Previously we only checked the exit block for being deoptimizing. Now we check if the last reachable block from the exit is deoptimizing.
So now we can consider a block deoptimizing if it meets the condition from the quote.
This should help peel loops which have profile data and which have such exits that all paths starting from them converge to a unreachable terminated block or a block which has a terminating deopt call.
clang-format: please reformat the code