================
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -fclangir -emit-cir %s -o - | \
+// RUN: cir-opt -cir-loop-distribution -o /dev/null 2>&1 | \
+// RUN: FileCheck %s --implicit-check-not=remark:
+
+double A[8][4], B[4][8], C[4][4], D[4][4];
+
+void candidate(void) {
----------------
SharmaRithik wrote:
Thanks for looking into this. Here are three cases in this situation with the
C++ example from Godbolt.
1. With O3 and Loop Distribution, Clang and CIR keep the inner k loop scalar
and unroll it by 8. LLVM Loop Distribution skips the inner k loop because it
only distributes loops to isolate unsafe memory dependence cycles, and this
loop has none. Its diagnostic only says that the memory accesses are safe.
Vectorization still cannot change the floating point addition order, and the
strided loads are costly.
2. With O3 and SLP vectorization, both outputs are still scalar and unrolled by
8. O3 already enables SLP, and the running sum leaves no independent additions
for SLP to group.
3. With O3, Loop Distribution, and SLP vectorization, the result is unchanged
because neither pass transforms the loop. Fast math lets direct Clang vectorize
with width 4 and interleave 4, but CIR stays scalar because its LLVM IR does
not contain the fast math flags.
This is a good chance for ClangIR to do something the LLVM IR passes miss.
ClangIR still knows the loops and the array shapes, so it can pull the C[i][j]
= 0 step out and swap the loop order to put j on the inside. Now each step
writes a different C[i][j] instead of adding into the same running sum, so
there is no running sum to reorder. That loop is easy to vectorize at plain O3
with no fast math, and since k stays on the outside, every value is added in
the same order as before, so the answer does not change.
https://github.com/llvm/llvm-project/pull/209933
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
