Previously we had two-dimensional accesses to store packed operands of the matrix multiplication for the sake of simplicity of the packed arrays. However, addition of the third dimension helps to simplify the corresponding memory access, reduce the execution time of isl operations applied to it, and consequently reduce the compile-time of Polly. For example, in case of Intel Core i7-3820 SandyBridge and the following options,
clang -O3 gemm.c -I utilities/ utilities/polybench.c -DPOLYBENCH_TIME -march=native -mllvm -polly -mllvm -polly-pattern-matching-based-opts=true -DPOLYBENCH_USE_SCALAR_LB -mllvm -polly-target-cache-level-associativity=8,8 -mllvm -polly-target-cache-level-sizes=32768,262144 -mllvm -polly-target-latency-vector-fma=7
it helps to reduce the compile-time from about 361.456 seconds to about 0.816 seconds.
Wouldn't it make more sense to check for the access relation instead for the generated code?
I mean, there are a lot suffix digits in the checks which can change easily with otherwise unrelated changes, including with LLVM itself.
The change is also unrelated to matrix-multiplication optimization. Is there a simpler test case?
If I understand your summary correctly, this is only a compile-time optimization. How can there be a test case?