[llvm] [DA] Fix the check between Subscript and Size after delinearization (PR #151326)

Michael Kruse via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 5 07:49:53 PDT 2025


================
@@ -594,14 +594,15 @@ for.end12:                                        ; preds = %for.inc10, %entry
 }
 
 
+; FIXME? It seems that we cannot prove that %N is non-negative...
 define void @nonnegative(ptr nocapture %A, i32 %N) {
 ; CHECK-LABEL: 'nonnegative'
 ; CHECK-NEXT:  Src: store i32 1, ptr %arrayidx, align 4 --> Dst: store i32 1, ptr %arrayidx, align 4
-; CHECK-NEXT:    da analyze - none!
+; CHECK-NEXT:    da analyze - output [* *]!
 ; CHECK-NEXT:  Src: store i32 1, ptr %arrayidx, align 4 --> Dst: store i32 2, ptr %arrayidx, align 4
-; CHECK-NEXT:    da analyze - consistent output [0 0|<]!
+; CHECK-NEXT:    da analyze - output [* *|<]!
 ; CHECK-NEXT:  Src: store i32 2, ptr %arrayidx, align 4 --> Dst: store i32 2, ptr %arrayidx, align 4
-; CHECK-NEXT:    da analyze - none!
+; CHECK-NEXT:    da analyze - output [* *]!
----------------
Meinersbur wrote:

> So, what happens when `%N` is `INT32_MIN`? When `%h.045` is 0, `%mul` is also 0, and `%add` has the same value as `%i.043`. 

Since `%N` is unsigned, its value should be interpreted as `UINT32_MAX`. But dang, I only considered the inner loop. With getementptr/add you can add any invariant value and the result would is injective (different `%h.045` results in different `%arrayidx`), not that I would assume DA would consider that. `inbounds` and therefore `poison` only applies to what `getelementptr` does (for the sake of the argument, assume that `%A` is zero in kernel-space in a memory block that spans the entire virtual memory space -- no wrapping behaviour can happen here), but the `mul` is variant in the outer loop and might wrap / has no no-wrap flag.

So the store 1 -> store 1 self-dependency might be something like `output [* <]`. Again , not something I expect DA to figure out.

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


More information about the llvm-commits mailing list