[Mlir-commits] [mlir] [MLIR][tensor] Improve `tensor.pack` verifier to catch more cases with unconditional runtime errors (PR #77217)

[Renato Golin]

rengolin wrote:

> This has never been, and continues to not be, a factor for upstream MLIR. If it is the right thing to do we should, if not that's ok. Arguing design positions based on breaking downstream projects is dangerous: it gives the wrong incentives as it pigeonholes evolution.

Strong support for this statement.

> * we can remove UB by always requiring the padding value to be specified. It generally seems desirable to me to avoid needlessly introducing UB and special runtime cases.

I wonder what is the value of requiring an actual value at run time. IIUC, the padding is just the remainder of the division of the run time dimension by the run time tiling factor, on the last tile. Anything else would make no sense. Requiring users/lowering to add a `mod` op for the padding value seems redundant. Just a flag to pad to the nearest multiple on the last tile would do, probably.

If the source language "defines" undefined behaviour for run time cases (like C++), then we let it by pass. If not, then they're responsible for lowering run time checks to IR and do what they normally would do (crash, trap, raise exception). It is not a job for the IR to know what.

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