[all-commits] [llvm/llvm-project] 773e15: [mlir][linalg] Restrict linalg.pack to not have ar...

[Han-Chung Wang via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 773e158c64735a80b814f20be6b959d9577531f8
      https://github.com/llvm/llvm-project/commit/773e158c64735a80b814f20be6b959d9577531f8
  Author: Han-Chung Wang <hanhan0912 at gmail.com>
  Date:   2025-07-25 (Fri, 25 Jul 2025)

  Changed paths:
    M mlir/include/mlir/Dialect/Linalg/IR/LinalgRelayoutOps.td
    M mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp
    M mlir/lib/Dialect/Linalg/Transforms/PackAndUnpackPatterns.cpp
    M mlir/test/Dialect/Linalg/canonicalize.mlir
    M mlir/test/Dialect/Linalg/data-layout-propagation.mlir
    M mlir/test/Dialect/Linalg/invalid.mlir
    M mlir/test/Dialect/Linalg/transform-lower-pack.mlir
    M mlir/test/Interfaces/TilingInterface/tile-and-fuse-consumer.mlir

  Log Message:
  -----------
  [mlir][linalg] Restrict linalg.pack to not have artificial padding. (#150522)

The revision restrict the `linalg.pack` op to not have artificial
padding semantics. E.g., the below is valid without the change, and it
becomes invalid with the change.

```mlir
func.func @foo(%src: tensor<9xf32>) -> tensor<100x8xf32> {
  %cst = arith.constant 0.000000e+00 : f32
  %dest = tensor.empty() : tensor<100x8xf32>
  %pack = linalg.pack %src
    padding_value(%cst : f32)
    inner_dims_pos = [0]
    inner_tiles = [8] into %dest
    : tensor<9xf32> -> tensor<100x8xf32>
  return %pack : tensor<100x8xf32>
}
```

IMO, it is a misuse if we use pack ops with artificial padding sizes
because the intention of the pack op is to relayout the source based on
target intrinsics, etc. The output shape is expected to be
`tensor<2x8xf32>`. If people need extra padding sizes, they can create a
new pad op followed by the pack op.

This also makes consumer tiling much easier because the consumer fusion
does not support artificial padding sizes. It is very hard to make it
work without using ad-hoc patterns because the tiling sizes are about
source, which implies that you don't have a core_id/thread_id to write
padding values to the whole tile.

People may have a question how why pad tiling implementation works. The
answer is that it creates an `if-else` branch to handle the case. In my
experience, it is very struggle in transformation because most of the
time people only need one side of the branch given that the tile sizes
are usually greater than padding sizes. However, the implementation is
conservatively correct in terms of semantics. Given that the
introduction of `pack` op is to serve the relayout needs better, having
the restriction makes sense to me.

Removed tests:
-
`no_bubble_up_pack_extending_dimension_through_expand_cannot_reassociate`
from `data-layout-propagation.mlir`: it is a dup test to
`bubble_up_pack_non_expanded_dims_through_expand` after we fix the
shape.
- `fuse_pack_consumer_with_untiled_extra_padding` from
`tile-and-fuse-consumer.mlir`: it was created for artificial padding in
the consumer fusion implementation.

The other changes in lit tests are just fixing the shape.

---------

Signed-off-by: hanhanW <hanhan0912 at gmail.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications