[Mlir-commits] [mlir] Revert "[mlir][tensor] Refine the semantics of `createPadHighOp`" (PR #110153)

[Andrzej Warzyński]

banach-space wrote:

> It is technically a NOP, but we still need to generate the pad op. Because there is a `nofold` attribute. This is controlled by `pack_paddings` in the transform op. A scenario of using these transformation is to hint the bufferization to create an intermediate buffer (e.g., stack buffer on CPU's land), and it is sort of preparation for vectorization. In one of use cases, we can `tile parallel loops -> pad parallel dimensions-> tile reduction loops -> pad reduction dimensions` to enable the vectorization for dynamic shapes. The chain of `extract_slice -> pad (foldable) -> extract_slice -> pad (nofold)` can be folded into a single pad op by [FoldOrthogonalPaddings pattern](https://github.com/llvm/llvm-project/blob/c11722223bacf604e60414542743d021a9f13aee/mlir/lib/Dialect/Tensor/IR/TensorOps.cpp#L3147-L3183). I think we want to keep the pass working, so we don't want to break linalg::padAndHoistLinalgOp's behavior.

Thank you for the explanation, that's very helpful 🙏🏻  I need a bit more time to parse this in the context of scalable vectors, and, indeed, work on padding for SVE (which would be a valid lowering path). 

Interestingly, in your example you are padding the static dim and for dynamic dims the transformation fails elsewhere. And my intent was to catch cases where both the input and output dims are dynamic. I failed miserably, but at least we've found a gap in our testing. And my assumption seems to hold (at least one dim should be static).

I've added some tests to capture this and a couple other cases: 
* https://github.com/llvm/llvm-project/pull/110271

This should protect us from my mistakes in the future. I will also try to refine the original PR later on.

Btw, this made me wonder - why `pack_paddings` and not `nofold` 🤔 ? 

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