[llvm] [LoopPeel] Support peeling last iteration with multiple exits. (PR #141247)

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Wed May 28 10:24:30 PDT 2025


preames wrote:

I think you might be approaching this in a non-ideal way.  Let me try to expand, this as much me thinking out loud as anything else.
1) Single exit loops which exit through the latch don't change with this patch.
2) Single exit loops which exit through non-latch might regress with this change.  This is unlikely to matter in practice because we rotate such loops to become latch exiting.
3) Multiple exit loops with entirely analyzeable exits regress with this change.
4) Multiple exit loops with an analyzeable latch exit, but unanalzeable non-latch exits improve.
5) Multiple exit loops with an unanalyzeable latch exit, but other analyzeable exits don't change.

I think the better way to approach this is to identify the set of analyzeable exits which dominate the sole latch (i.e. the backedge), and peel that instead of BTC.  This would have the effect of removing all analyzable exits in one go.  (By having the dispatch between the exits in the peeled iteration.)

Implementation wise, this is what the SymbolicMaximum exit count kind in SCEV actually computes, but isn't what the documented contract is.  I think the existing users would be fine with the revised contract, and may even rely on it today.

I don't know if we can rely on generic folding to recognize that every analyzeable exit count must be greater than the symbolicmax - 1, so we might need to manually fold all the exits after peeling off the last iteration.  

https://github.com/llvm/llvm-project/pull/141247


More information about the llvm-commits mailing list