Loop tiling and loop ordering in MLIR

Hello, I’m relatively new to understanding MLIR and its use cases. I’m interested in learning about the passes in MLIR in the context of optimizations for dense matrix/dense linear algebra operations. More specifically the LoopTiling pass.

I see here, in the comment on line#88, that loop tiling sizes in MLIR are determined based on the fact whether the tiles “fit” in the memory or not. However, there are several frameworks such as TVM, Timeloop, dMazeRunner etc. that have shown loop tiling (and loop ordering) to be a complicated problem. There are several factors affecting best tiling and ordering strategy for running loop-nests for dense arrays on hardware architecture such as levels of memory hierarchy, memory sizes, number of PEs, ranges of each of the loop dimensions etc. And several frameworks have proposed different search algorithms to find the best tiling and ordering for loop-nests on dense arrays.

My question is, does MLIR implements any sophisticated method to perform loop-nests optimization (that I may have missed)? Or is this not the scope of work for MLIR?

I’d appreciate any help regarding this.

Thanks in advance


The utilities to perform such transformations (tiling, interchange, fusion, packing, memref layout change, etc.) do exist, but cost functions/heuristics or cost model-driven frameworks to optimize for the various hardware characteristics like the ones you list don’t exist in the transformation passes that accompany loop nest dialects (like affine). There is also scope to further improve and extend the utilities as well.

What you noticed in the affine loop tiling pass is a simple strategy or a starting point. It might as well be moved out to a test pass or generalized to something more concrete with the underlying utilities made reusable to build various cost model-driven frameworks.

Thank you for the prompt reply. If I understand correctly, a cost-model driven approach for optimization could be rather thought of as a “plugin” to MLIR.

A helpful way to understand the ecosystem is to think of MLIR as of a library for building compilers, rather than an end-to-end compiler. You can use it to build an optimizing compiler with optimization driven by whatever you see fit, but the bar of putting this driver into the main code base is very high.

@ftynse Thank you, that explains my concern.