Linalg ops are perfect loop nests. When materializing the concrete
loop nest, the default order specified by the Linalg op's iterators
may not be the best for further CodeGen: targets frequently need
to plan the loop order in order to gain better data access. And
different targets can have different preferences. So there should
exist a way to control the order.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks much nicer than what I had feared.
I was originally thinking that this should rather convert to linalg.generic, apply interchange on the generic representation and not change the LinalgToLoops transformation but this actually looks reasonable.
This may still run into longer term issues re. transformation composition and confluence: in particular sparse linalg will want to have its own order and the prototype sparsification transformation performs its own ordering.
I still think in the future we may have to compose everything at the generic level but I don't see a compelling reason to avoid this modification to the LinalgToLoops transformation today.
Yup, agreed. I prototyped both but will use the linalg generalization path. I remembered that Mahesh said this could be useful to other use cases so also sending it out.