[Mlir-commits] [mlir] [mlir][linalg] Restrict linalg.pack to not have extra padding sizes. (PR #149624)

[llvmlistbot at llvm.org]

https://github.com/Max191 commented:

I can give a real review later, but the idea of this sounds good to me. Having a linalg.pack with a whole bunch of extra padding is limiting for fusions, and I expect it would be simpler to deal with the pad and pack separately in that case.

Perhaps a separate discussion, but would the same logic apply to linalg.unpack with its extract_slice semantics too? It doesn't seem to me like unpack has the same problems as pack, but do we want to keep the semantics consistent?

The difficulty with pack is that the padding semantics are hard to handle with fusions. Fusing a consumer pad is hard because you may need to produce a result that is larger than the total output spanned by the tiling loop. This means you need to either expand the iteration space of the loop or have some iterations of the loop produce some extra results.

However, the same difficulty does not really arise with tensor.extract_slice, since no new values are created. This means that the problems we see for linalg.pack don't exist for linalg.unpack, so I'd probably argue that we should not update the unpack semantics to match these new pack semantics, but WDYT?

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