[Mlir-commits] [mlir] [mlir][gpu] Add pass for emulating unsupported types. (PR #138087)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Tue May 6 14:56:24 PDT 2025


MaheshRavishankar wrote:

Skimmed through the change again, and I think my main concern of the linearization bits have been solved. Just my two cents if it helps resolve the deadlock here.

First of all, @mshahneo  thanks for working through this and making a fairly flushed out implementation with tests.  I fully believe this solves the problem you are encountering, and I am sure other folks have hit this problem as well and would be a good common resource.

I have a few follow up questions though. It is not immediately clear to me what is the scope of this change. For example, 
1) what would happen for the case of `i4` or any sub-byte type. How is this supposed to be handled? This falls within the scope of the sub-byte emulation support that exists in tree. 
2) How would this work for dialects that are not in tree. It seems like for this pass to work it will need to support all operations within the function. But if someone is using this in a function mixing operations from dialects in core, and downstream dialects, then this pass would break. So in that sense this pass is very fixed function.

In general it would have probably been better to get some community discussion going with RFC. Having an implementation like this actually makes the RFC stronger, but is a better forum to discuss than a PR. Another aspect to consider is the maintainability of the pass. When this lands in main, someone needs to be the defacto owner of it (ideally one of the existing folks who think this is a valuable thing to add and take on the maintainence of this). I know creating RFCs is kind of a pain, but MLIR does suffer a lot with abandoned dialects/methods/transformations that just become a maintainence burden now.

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


More information about the Mlir-commits mailing list