[Mlir-commits] [mlir] [MLIR][Linalg] Add boundary fill option to pad fusion pass (PR #223792)

[Renato Golin]

rengolin wrote:

The main problem with this PR is that it tries to fix a low level problem in a high level representation. You create a state at this level that has very specific hardware semantics and has to be lowered to a particular hardware pattern with little chance of error. That's why you ended up with so many inconsistencies to deal with.

My advice is to look at this from a lower level POV. Lower this to vector level and create a specialist pattern that fixes the loop/vector code. At the Linalg level you can use the transforms to move the code to a good lowering shape, and then you can make your special tricks.

This is one example: https://arxiv.org/abs/2511.13764

> For the performance results, using Claude was honestly just easier than writing the harness and graphing code myself.

Easier, not better. Good harnesses are hard to come by and even harder to trust. Claude doesn't even make the right assumptions about code most of the time, let alone something as crafty as benchmarking. Generating and plotting numbers you don't 100% know where they come from have the opposite effect you expect: they misinform rather than just being unhelpful.

> For future PRs, what is the preferred way to show performance gains? Is a small human-written benchmark more convincing, even if the generated harness is also shared?

Performance is relative. It's _very_ common to gain 50% on a micro-benchmark and lose 1% on a real use-case. Writing the benchmark by hand is a sure way of not getting the end performance you wanted in the first place.

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