[llvm] [polly] [DA] Add batch delinearization support for improved precision (PR #170519)

[Ryotaro Kasuga via llvm-commits]

================
@@ -0,0 +1,147 @@
+; 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
+
+; Test case for batch delinearization. When multiple accesses to the same
+; base pointer are analyzed together, terms from all accesses are collected
+; to determine array dimensions, leading to better precision.
+;
+; This test has three accesses to array A:
+;   A[i*m + j]  (in the write)
+;   A[i*m + j]  (in the read)
+;   A[k*m + l]  (third access that provides additional context)
+;
+; The third access helps provide more terms for delinearization,
+; which can improve precision when analyzing the first two accesses.
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; Three accesses to the same 2D array A[n][m].
+; Batch delinearization collects terms from all accesses.
----------------
kasuga-fj wrote:

The problem is not the bound checks. Probably they passed. Consider what happens in the case where `m = 2^61`. As `sizeof(double) == 8`, the address calculation would be:

$A + (i \times m + j) \times 8 = A + (i \times 2^{61} + j) \times 8 = A + 2^{64} i + 8 j$

It means that `&(%A[0][%j]) == &(%A[1][%j]) == ... == &(%A[%n - 1][%j])`, but DA assumes `&(A[i0][j0]) == &(A[i1][j1])` iff `i0 == i1 && j0 == j1`. To make things safe, we need some overflow checks in addition to array bound checks.

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