Generic LICM?

Hello!

I’m exploring the different LICM approaches currently implemented in MLIR. We have at least three that I’m aware of: Affine LICM [1], interface-based LICM [2] and Linalg hoisting [3]. Affine LICM seems to be the most advanced in terms of functionality. It’s able to hoist memory operations but only if they are affine (affine.load, affine.store, etc.). The interface-based LICM uses some interfaces (LoopLikeOpInterface, MemoryEffectOpInterface, …), I guess, aiming at being more generic and work on any dialect, including any kind of memory operation. However, this one is not currently able to hoist memory operations (std.load, std.store, affine.load, affine.store, vector.transfer_read, vector.transfer_write, etc.), which is an important limitation. Finally, Linalg hosting uses the interfaced-based LICM to implement a more sophisticated LICM transformation for some special cases that include vector read and write ops.

It would be great to get some context about this and to know about any related plans. Is the goal to integrate the Affine version into the interface-based version? Are all the pieces needed (op interfaces, analysis interfaces (?), etc.) in place for that to happen? What about the Linalg hosting? Is that something that we could use outside Linalg?

Thanks!
Diego

@bondhugula, @River707, @nicolasvasilache, @_sean_silva

[1] lib/Dialect/Affine/Transforms/AffineLoopInvariantCodeMotion.cpp
[2] lib/Transforms/LoopInvariantCodeMotion.cpp
[3] lib/Dialect/Linalg/Transforms/Hoisting.cpp

I wrote the interface based one a while back and at that point, we had no alias/dependence analysis available to reason about reads and writes. I think we still do not have a generic framework for this and instead, we have specific implementations for the two systems that support this, affine and linalg.

The current effects system’s granularity is not fine enough for this and I am also not convinced whether it would be the right abstraction. So a first step would be to come up with a generic interface to model the required analysis. We likely won’t be able to mix affine and linalg that way but at least we could share the implementation of LICM.

It would be great but I am not aware of any effort in that direction.

Thanks, Stephan!

So a first step would be to come up with a generic interface to model the required analysis. We likely won’t be able to mix affine and linalg that way but at least we could share the implementation of LICM.

Yeah, if we could decouple the analysis from the transformation, we could reuse the transformation part. I guess that wouldn’t be that complicated because LICM is just moving instructions around but not creating new instructions. However, if we don’t have the bits for alias/dependence analysis for the Standard or Vector dialects, I’m not sure we would gain much functionality-wise at this point.

Thanks for the info!