[clang] [CIR] Recognize loop distribution candidates (PR #209933)

[Rithik Sharma via cfe-commits]

================
@@ -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