[llvm] [PGO] Add llvm.loop.estimated_trip_count metadata (PR #152775)

Joel E. Denny via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 19 13:13:33 PDT 2025


jdenny-ornl wrote:

> > With or without this PR, `{get,set}LoopEstimatedTripCount` operate on the branch weights of a loop's only latch (and they reject loops with more latches). My expectation is that merely moving the estimated trip count to loop metadata on that latch for each of the same loops should not worsen the above issue.
> 
> To be clear, the concern is not about loops with multiple latches, but two loops sharing one latch. You can have an inner loop latch that exits into an outer loop and is the latch of the outer loop. IIRC that's possible even in loop simplify form.

I was trying to make a point about how, for a loop with one latch, all this PR is doing is changing which metadata on that latch encodes the estimated trip count.

After further thought, I realize that the `branch_weights` metadata on a latch distinguishes an outer loop from an inner loop because each loop header is a different successor of the latch.  But `llvm.loop.estimated_trip_count` does not distinguish the loops.

I think I have a workaround.  I have adjusted getExpectedExitLoopLatchBranch to guard `{get,set}LoopEstimatedTripCount` as it does without this PR. getExpectedExitLoopLatchBranch will not recognize the same latch for both loops unless the latch exits both loops and has only two successors.  However, to exit both loops, the latch must have at least three successors: the inner loop header, the outer loop header (exit for the inner loop), and an exit for the outer loop.

Does that seem reasonable?

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


More information about the llvm-commits mailing list