[Mlir-commits] [mlir] [MLIR][Linalg] Add static shape masking option in vectorization (PR #214812)

Renato Golin llvmlistbot at llvm.org
Fri Aug 14 00:47:38 PDT 2026


rengolin wrote:

> This PR introduced an _additional source of information_ - **user specified bounds**.

IIUC, semantically speaking, this is _architecture specific_ bounds, not user. We may argue about implementation in separate, but the bound I understood is just for the "ops to fit the static tile shapes they need". The mask then just deals with the last tile.

> > trailing elements must not contribute to the result
> 
> OK, so for that we'd use a neutral element.

or masking...

> Makes sense, but from what I can tell, the input Linalg is already incorrect (it became incorrect at the point of padding). Am I missing something?

Yes. If padding is done _before_ masking, then the input has incorrect semantics until masking is added, _because_ the input is used for two different neutral element reductions. They need to be done in one go, so that it's never incorrect.

> 1. If you are hoping to use masking, why do you need to pad?

Pad is a _physical_ problem (need to be loaded as a statically sized block), while masking is a _logical_ problem (only the first N elements of the padded shape count).

For a single reduction user (or same neutral element), just padding is fine. For different padding values, you need masking.

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


More information about the Mlir-commits mailing list