[Mlir-commits] [mlir] [mlir] [linalg] fix failure on specializing matmul with permuted loops (PR #184294)

[llvmlistbot at llvm.org]

ziereis wrote:

> Still worried we're forcing the maps to be in a canonical shape without verifying that that was the case in the original generic. Transpose, broadcast, weird access. At the very least more tests are needed to make sure we cover all the cases this time.

I can add more tests that cover different loop ordering + transpositions. 

> Also thinking that, if a generic has "non-canonical" loop order, then maybe it's done on purpose? Some other compiler pass is doing this to optimize memory access, and then we go on and revert that change? So, perhaps, if the generic has non-canonical order, we shouldn't convert into a matmul?

>From my understanding a core property of linalg is that we do not embed any scheduling information into the operation itself. Which does mean that i should be always free to reorder the iterator_types in any way i want because the order carries no meaning for how i would materialize the actual loop nest.

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