[Mlir-commits] [mlir] [mlir][linalg] Move vectorization tests for pad + insert_slice Ops (nfc) (PR #140877)
Andrzej Warzyński
llvmlistbot at llvm.org
Thu May 22 02:57:50 PDT 2025
banach-space wrote:
Hey @hanhanW - you've raised a lot of great points, thanks!
I do have a target end-state in mind that I’m trying to converge toward, and I should’ve communicated that more clearly - sorry about that. Here's a quick summary of the overall direction:
* https://github.com/llvm/llvm-project/issues/141025
This PR is just a small step in that direction. It’s intended to make one of my upcoming patches a bit easier to review (at least that’s the hope!).
> I think your rule may be moving all vectorization tests of non-linalg ops to vectorization/ directory, but it is not obvious IMO
Yes - at a minimum, I’d like to extract non-Linalg ops from "vectorization.mlir" and "vectorization-with-patterns.mlir". We already have a dedicated file for tensor.extract, so doing the same for other non-Linalg ops would bring more consistency.
(Btw, let me rename+move "vectorize-tensor-extract-masked.mlir" + "vectorize-tensor-extract.mlir" as part of this change - to avoid sending too many PRs).
> I don’t have issues finding tests
That's because you know this stuff too well! 😄
But from a different angle - when updating vectorization logic for something like `linalg.pack` and `linalg.unpack` (which use custom hooks), wouldn’t it be cleaner if we had dedicated test files for just those two ops? That way, the corresponding PR would only touch "vectorize-pack-unpack.mlir", and if something breaks inside `vectorizeAsTensorPackOp` or `vectorizeAsTensorUnPackOp`, triaging would be much simpler.
These changes aren’t critical, but they do address some real friction I’ve experienced while updating or reviewing code. It’s mostly about future-proofing and making long-term maintenance easier.
Hope this makes sense!
https://github.com/llvm/llvm-project/pull/140877
More information about the Mlir-commits
mailing list