This is an archive of the discontinued LLVM Phabricator instance.

[mlir][linalg] Support permutation when lowering to loop nests
ClosedPublic

Authored by antiagainst on Nov 19 2020, 6:34 AM.

Details

Summary

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.

Diff Detail

Event Timeline

antiagainst created this revision.Nov 19 2020, 6:34 AM
antiagainst requested review of this revision.Nov 19 2020, 6:34 AM
nicolasvasilache accepted this revision.Nov 19 2020, 6:59 AM

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.

This revision is now accepted and ready to land.Nov 19 2020, 6:59 AM

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.