[Mlir-commits] [mlir] [mlir][vector] Add vector.transpose with unit-dim to vector.shape_cast pattern (PR #72105)

[Lei Zhang]

antiagainst wrote:

Sorry for being the "blocker" on moving forward--in my mind it's actually common in LLVM/MLIR land to revert if something causes an issue. We see that happening quite a bit. It's a good balance that gives us development velocity while catering to all party's needs. :)

Regarding the specific issue here (shape_cast), generally in SPIR-V we can only have 1-D vectors (with at most 4 elements by default). We need to rely heavily on vector unrolling and various kinda cancelling (of pairing insert/extrat slices, etc.) to break high-D vectors down to 1-D. The flow works for existing transpose and such; we need to figure out how to do the same with shape_cast and such. It's quite tricky and more "annoying" than LLVM side, where we can sometimes relying on LLVM proper to do the "magic" for us. We do have more control by doing everything by ourselves in MLIR actually. Seemingly annoying, I would say that SPIR-V puts quite some requirements and demands in MLIR to harden various pieces of vector dialect conversions and such--I personally added a lot of vector related patterns over the years to add various functionalities and fix various kinds of corner cases that aren't necessary if we only consider LLVM.

Regarding tests, I totally understand the desire; and we should definitely try. But to have a negative test for all kinds of pontentially breaking things in the future is hard; in a sense that's kinda demanding we forsee all future issues. :) Also given the multi-step nature of MLIR, certain issues only arise if we compose quite some patterns and steps together. That would mean we have lots of specificially designed one-off integration tests. We can see lots of combinations there. Generally we don't have much such tests in tree I think.

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