[llvm] [LAA] Be more careful when evaluating AddRecs at symbolic max BTC. (PR #128061)

[Florian Hahn via llvm-commits]

================
@@ -72,10 +72,10 @@ define void @all_exits_dominate_latch_countable_exits_at_most_500_iterations_not
 ; CHECK-NEXT:          %gep.A = getelementptr inbounds i32, ptr %A, i64 %iv
 ; CHECK-NEXT:      Grouped accesses:
 ; CHECK-NEXT:        Group [[GRP3]]:
-; CHECK-NEXT:          (Low: %B High: (2000 + %B))
+; CHECK-NEXT:          (Low: %B High: inttoptr (i64 -1 to ptr))
 ; CHECK-NEXT:            Member: {%B,+,4}<nuw><%loop.header>
 ; CHECK-NEXT:        Group [[GRP4]]:
-; CHECK-NEXT:          (Low: %A High: (2000 + %A))
+; CHECK-NEXT:          (Low: %A High: inttoptr (i64 -1 to ptr))
----------------
fhahn wrote:

> Ignoring the fact that the GEPs in the loop explicitly say there is no wrapping (due to inbounds), it sounds like this patch is saying that for early exit loops 2000+%A could wrap (hence the need to clamp the value), but for normal loops 2000+%A cannot wrap (hence we don't need to clamp). I'm just struggling to understand the reasoning behind this. Having said that, I'm happy to accept this limitation for now if it makes life easier and helps to solve the immediate issue.

Technically the GEPs say that the result is poison if it is not inbounds. Dereferencing the poison GEP would trigger UB. 

Say 1000+%A wraps. When there's no early exit, 2000+%A would still wrap, but guaranteed to trigger UB in the original loop, because the loop must access memory range %A..2000+%A.

If there is an early exit, the original loop may always exit before accessing 1000+%A, so would not trigger UB, but we would expand 2000+%A, which would have wrapped and the runtime check would incorrect.

Hope that makes sense.



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