[DA] Add test where access size differs from stride size (NFC)

[kasuga-fj]

Add a test case that is mentioned in #144088 but not added yet.

[llvmbot]

@llvm/pr-subscribers-llvm-analysis

Author: Ryotaro Kasuga (kasuga-fj)

Changes

Add a test case that is mentioned in #144088 but not added yet.

---

Full diff: https://github.com/llvm/llvm-project/pull/147715.diff

1 Files Affected:

• (modified) llvm/test/Analysis/DependenceAnalysis/DifferentOffsets.ll (+47-1)

diff --git a/llvm/test/Analysis/DependenceAnalysis/DifferentOffsets.ll b/llvm/test/Analysis/DependenceAnalysis/DifferentOffsets.ll
index 05df105ef79c2..4f95da4f79c57 100644
--- a/llvm/test/Analysis/DependenceAnalysis/DifferentOffsets.ll
+++ b/llvm/test/Analysis/DependenceAnalysis/DifferentOffsets.ll
@@ -149,11 +149,11 @@ define void @multidim_accesses(ptr %A) {
 ; CHECK-NEXT:  Src: store i32 1, ptr %idx0, align 4 --> Dst: store i32 1, ptr %idx0, align 4
 ; CHECK-NEXT:    da analyze - none!
 ; CHECK-NEXT:  Src: store i32 1, ptr %idx0, align 4 --> Dst: store i32 1, ptr %idx1, align 4
-; FIXME: the dependence distance is not constant. Distance vector should be [* * *|<]!
 ; CHECK-NEXT:    da analyze - consistent output [0 0 0|<]!
 ; CHECK-NEXT:  Src: store i32 1, ptr %idx1, align 4 --> Dst: store i32 1, ptr %idx1, align 4
 ; CHECK-NEXT:    da analyze - none!
 ;
+; FIXME: the dependence distance is not constant. Distance vector should be [* * *|<]!
 ; for (i = 0; i < 256; i++)
 ;   for (j = 0; j < 256; j++)
 ;      for (k = 0; k < 256; k++) {
@@ -199,3 +199,49 @@ for.i.inc:
 end:
   ret void
 }
+
+; for (int i = 0; i < 256; i++)
+;   for (int j = 0; j < 256; j++)
+;      for (int k = 0; k < 256; k++) {
+;        int *idx = (int *)((int *)(A) + 256*256*i + 256*j + k);
+;        *((long long *)idx) = 1;
+;      }
+;
+; FIXME: There are loop-carried dependencies across iterations in the store.
+define void @multidim_accesses2(ptr %A) {
+; CHECK-LABEL: 'multidim_accesses2'
+; CHECK-NEXT:  Src: store i64 1, ptr %idx, align 4 --> Dst: store i64 1, ptr %idx, align 4
+; CHECK-NEXT:    da analyze - none!
+;
+entry:
+  br label %for.i
+
+for.i:
+  %i = phi i64 [ 0, %entry ], [ %i.inc, %for.i.inc ]
+  br label %for.j
+
+for.j:
+  %j = phi i64 [ 0, %for.i ], [ %j.inc, %for.j.inc ]
+  br label %for.k
+
+for.k:
+  %k = phi i64 [ 0, %for.j ], [ %k.inc, %for.k ]
+  %idx = getelementptr inbounds [256 x [256 x [256 x i32]]], ptr %A, i64 0, i64 %i, i64 %j, i64 %k
+  store i64 1, ptr %idx
+  %k.inc = add nsw i64 %k, 1
+  %k.exitcond = icmp eq i64 %k.inc, 256
+  br i1 %k.exitcond, label %for.j.inc, label %for.k
+
+for.j.inc:
+  %j.inc = add nsw i64 %j, 1
+  %j.exitcond = icmp eq i64 %j.inc, 256
+  br i1 %j.exitcond, label %for.i.inc, label %for.j
+
+for.i.inc:
+  %i.inc = add nsw i64 %i, 1
+  %i.exitcond = icmp eq i64 %i.inc, 256
+  br i1 %i.exitcond, label %end, label %for.i
+
+end:
+  ret void
+}

[kasuga-fj]

As I mentioned in #145050 (comment), this case reveals a new issue that is not triggered by any of the existing cases.