We can end up with two loop exits whose exit counts are equivalent, but whose textual representation is different and non-obvious. For the sub-case where we have a series of exits which dominate one another (common), eliminate any exits which would iterate *after* a previous exit on the exiting iteration.
As noted in the TODO being removed, I'd always thought this was a good idea, but I've now seen this in a real workload as well. This needs to be rebased on D68956 as both need the same dominance order check.
Now that we're traversing the exits in dominating order, I think we should consider a slightly different overall approach:
Instead of computing umin({ exit counts }) upfront and then checking for umin({ exit counts }) < this exit count, we can instead build this up incrementally, i.e. take the umin between the current max exit count and the exit count of the currently considered exit at each iteration. This will allow us to check for umin({ already seen exit counts }) <= this exit count (note the <=!) instead.
This should implicitly handle the case of exact equalities, but may also be more powerful in general because we're checking for a weaker predicate.