[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