[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