[Mlir-commits] [mlir] [mlir][vector] Make `TransposeOpLowering` configurable (PR #73915)
Lei Zhang
llvmlistbot at llvm.org
Fri Dec 1 12:03:39 PST 2023
antiagainst wrote:
Thanks everyone and sorry about the late reply--I am really overwhelmed by some company internal tasks due to upcoming events so wasn't able to look into it as the absolute top priority.
I guess I can be categorized into one of the SPIR-V folks in MLIR. :) If we want to be specific, we only have Jakub and me as the daily maintainer recently there. Compared to the number of people actively helping on plumbing LLVM flow, I think we are certainly not that resource abudunt. :) Both of us are fully occupied with company upcoming launch events at the moment.
Hopefully this explains a bit why there are delays and we may want to temporary resort to workarounds--I don't want people to be under the impression that "SPIR-V folks" are just blocking everybody. FWIW, as @MaheshRavishankar said, we also contribute to a lot of other layers in MLIR, given that SPIR-V is just an exit and we prefer to handle issues at the proper layer. We all work on the same codebase. :)
I totally understand the desire to have a clean codebase in MLIR and that's what all we need to contribute to. FWIW, we have been helping to clean up quite a lot of things along the whole history of MLIR. I'd certainly make sure this is the top priority for me once I'm more freed. I really don't want to make @banach-space and other to continue waiting due to my inability to take care of this right now so I hope this is an okay intermedidate state before Dec 6th.
FWIW, we already have [4 different ways](https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/Vector/Transforms/VectorTransformsBase.td#L30) to control how `vector.transpose` is used, and I think we only use one of them for SPIR-V; all 4 different ways were motiviated by LLVM lowering I believe. I don't know all the trickiness there; but I'd think it's not that disruptive to just add the 5th way to lower to `vector.shape_cast`, to satisfy new constraints on scalable vectors on LLVM lowering path.
Let's move this forward please? :)
https://github.com/llvm/llvm-project/pull/73915
More information about the Mlir-commits
mailing list