[llvm] [DA] Add option to dump delinearization result in printing analysis (PR #157859)

Michael Kruse via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 3 12:38:39 PST 2025


================
@@ -1,10 +1,14 @@
 ; NOTE: Assertions have been autogenerated by utils/update_analyze_test_checks.py UTC_ARGS: --version 5
-; RUN: opt < %s -disable-output "-passes=print<da>" -aa-pipeline=basic-aa 2>&1 \
-; RUN: | FileCheck %s
+; RUN: opt < %s -disable-output "-passes=print<da>" -aa-pipeline=basic-aa \
+; RUN:     -da-dump-delinearization-result 2>&1 | FileCheck %s
 
 target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
 target triple = "thumbv8m.main-arm-none-eabi"
 
+; FIXME: It seems that we cannot prove that %m * %o doesn't signed wrap in
+; almost all cases. If it wraps, the delinearization result should be
+; discarded, otherwise the result can be incorrect.
+
----------------
Meinersbur wrote:

> The corresponding GEP has nusw.

I only see `getelementptr inbounds`.

In any case, this kind of reasoning that we can assume C because otherwise some other iteration will be UB is more than I would expect from DA[^1]. It is also not necessarily correct. If GEP returns poison you still need to dereference it to cause UB, which might not be the case if the access is guared within `if` conditions, or the loop `break`s before reaching that iteration.

I understand correctly this PR is for tracking changes for DA. I wouldn't expect deep analysis of preexisting test cases.

[^1]: Polly does actually does that, but it also need complete understanding of the entire control flow including `if` and `break`.

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


More information about the llvm-commits mailing list