[Mlir-commits] [mlir] [mlir][linalg] Genericize MapOp (PR #162742)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Fri Oct 24 17:34:05 PDT 2025


srcarroll wrote:

> Any frontend that is targeting the linalg dialect for conversion can choose to use linalg.map or not. If they have already chosen to use linalg.map then nothing will change for them after these changes because neither the definition nor the builder have changed.

@javedabsar1  This is actually not true. What I meant that there is no change to the builder function signature.  Obviously the builder has been modified to add the extra block arg. However, if the `bodyBuilder` function is passed then the logic for this should be unchanged for the most part. The size of the `ValueRange` will increase by one, but that's it.  If there's any logic in downstream that depends on that size in any way, then ya there will have to be a change, but it's highly trivial.  If the `bodyBuilder` function is not passed and the block along with its containing ops are inserted manually, then you will have to add an extra block arg, like what I did [here](https://github.com/llvm/llvm-project/pull/162742/files#diff-0ac35afc1b69aa317610007222292ae67d9792aa1d857a071384b7c16036ad72R582).  

Nevertheless, I think this a really trivial update for downstream users. Way more trivial than what most downstream users have to deal with when updating upstream.

I'd be happy to modify the builders further to make this as convenient as possible for others needs.

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


More information about the Mlir-commits mailing list