[Mlir-commits] [mlir] [mlir][vector] Make `TransposeOpLowering` configurable (PR #73915)
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Thu Nov 30 12:34:31 PST 2023
MaheshRavishankar wrote:
> > Could you clarify why this is an issue. I thought one of the problems with vector lowering was about not having control over how things are lowered. This seems to be along those lines. I think it is impossible to have all back ends handle all vector lowerings. I understand we don't want to diverge too much, but some amount of control exists already to control how vector lowering work based on user situation (outer product vs dot product, etc) so this is adding to that. If we want this to be supported on all back ends, then this needs to be verified that any vector lowering can lower on all back ends before it is added on the general path?
>
> Sorry, perhaps my comment was misleading. My concern is more about starting to avoid certain vector operations when targeting one backend, making that backiend compatible with only a subset of the vector dialect. It's not about making all the lowerings work for all the backends, it's about having at least **one** lowering that can lower each vector ops to each backend.
Yeah, make sense... but this is a missing piece, and kind of a chicken and egg problem. If it is done without control and used on any other backend where it is not supported, we run into a failure (as we did here). So if we want to make this supported on all backends, before this gets added without control, we need to verify it works on all backends (i.e. doesnt crash). Right now this is introducing a crash along one backend due to missing support. So might be "an order of work" thing. To make this be unconditional and used always need to get the SPIR-V backend to handle it. Till that is done/scoped out, this needs some control to opt-out?
https://github.com/llvm/llvm-project/pull/73915
More information about the Mlir-commits
mailing list