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

David Sherwood via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 20 02:53:37 PDT 2025


================
@@ -130,10 +130,10 @@ define i32 @all_exits_dominate_latch_countable_exits_at_most_1000_iterations_kno
 ; CHECK-NEXT:          %gep.A = getelementptr inbounds i32, ptr %A, i64 %iv
 ; CHECK-NEXT:      Grouped accesses:
 ; CHECK-NEXT:        Group GRP0:
-; CHECK-NEXT:          (Low: %B High: (4004 + %B))
+; CHECK-NEXT:          (Low: %B High: inttoptr (i64 -1 to ptr))
----------------
david-arm wrote:

This needs a TODO because we shouldn't be doing this for dereferenceable pointers, right? Surely if it's guaranteed to be dereferenceable that implies it should not wrap? For example, I'm struggling to see how a C++ object passed by reference to a function could be allocated across a wrapped address space and be legal. I would expect any attempt to actually use the object triggers undefined behaviour in the C++ specification. I realise there's more to life than C++ - this is just one example of course.

Also, if I've understood correctly it will significantly impact @huntergr-arm's work to enable vectorisation of early exit loops with loads and stores from dereferenceable memory.

Again, I'm happy to accept the patch as is, just saying that we should improve this in future if we ever want to make progress with early exit vectorisaton.

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


More information about the llvm-commits mailing list