[llvm] [DA] Fix the check between Subscript and Size after delinearization (PR #151326)
Ryotaro Kasuga via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 7 04:33:36 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 [* *]!
----------------
kasuga-fj wrote:
> > * It says that the AddRec in the GEP argument doesn't wrap. So, what about subscripts after delinearization? At the moment, I think it would also not wrap if sizes are also positive (signed sense? unsigned sense?).
>
> Thats exatly what I mentioned as well. I think "non-wrap" of the subscript has to be replaced with a notion of monotonocity of the SCEV expression.
Hm, it looks reasonable to me for now.
> > The result of the GEP being poison itself doesn't trigger UB. It will be triggered only when it is used as the pointer argument to a load/store. So, we might need to add some control-flow checks, to rule out cases like this:
>
> DA does not support loop versioning like LAA does, we cannot require additional checks. I aslo don't think it is even possible to find such an expression to figure out whether GEP results in poison. Since we can assume that the program we are analyzing has no UB, we can assume that any poison returned by GEP will not be used.
I didn't mean inserting additional checks, I'm considering the case where the input IR has such a condition. DA reasons about something based on the GEP flags ([example](https://github.com/llvm/llvm-project/blob/edeee824f044b834ec0bc8380afc345bb1a58f35/llvm/lib/Analysis/DependenceAnalysis.cpp#L1111-L1128)), but violating these flags doesn't trigger immediate UB. It actually triggered when it is used as, e.g.. pointer argument for load/store. I'm now wondering if this inference is only allowed when the value of the GEP is guaranteed to be used.
https://github.com/llvm/llvm-project/pull/151326
More information about the llvm-commits
mailing list