Ruled out "known after loop" case because it is something we do not want to deal with.

Thanks Florian! One example of where it helps is ULT check in test of D88087 (fails without this patch).

Added ULT check showing use of D87890

Reloaded with dedicated unit test to make it independent on underlying patches (the only dependency was test).

It seems that there is no way that SCEV can now both make this query and return true for it. I'm currently building a chain of patch that will fix the query responds. Hopefully with them we will be able to construct a test for it.

Addressed comments, fixed bug with non-loop true successor, added corresponding test.

Internal testing revealed bugs, look weird, investigating.

Moved code to proper place.

Rebased (no spam in test checks update).

Planning to move this code to other place and merge with D87834

Actually I'm not sure we need this. I could not construct a test where it would succeed.

Fixed comment.

Yes, I will try to construct such test.

Reframing the solution with accordance with @reames 's comment, starting from the most trivial cases and moving towards more complex ones.

Thanks for a clue Philip, you are kind of right, but I don't think we can fix exit count computation. Here's the motivating example:

define i32 @test_01(i32* %p) {
entry:
  %len = load i32, i32* %p, align 4, !range !0
  br label %loop

Same as above.

In D87274#2260451, @lebedev.ri wrote:

This seems pretty NFC-ish, not sure why it would require review.
SGTM

Looks good. Is it still not merged? :)

LGTM. Good catch! Need to think about API to make this more generic.

Seems that SCEV simplification is unable to exploit this fact when computing minimum. I think the right place to fix this is inside getMinExpr.

LGTM. Please wait for Roman if he has any objections.