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

[Nicolas Vasilache]

nicolasvasilache wrote:

> AFAIK, `shape_casts` are meant to be only for n-D to 1D/ 1D to N-D conversion.
> So lowering the transpose to a shape-cast here seems to violate that 

I do not know where this assumption is coming from: the op semantics are broader than this.

> This might need more discussion, but in the meantime can I suggest we revert this (and the follow up that moved it into a canonicalization, which is a bit more problematic in my view cause that is done without any user control).

Based on what I read here, I don't see a justification to revert this particular commit.
The commit that forces this on all users by way of canonicalization is fine to revert, as long as a proper test is introduced upstream to show SPIR-V limitations: the issue should have been caught upstream.

> In general `shape_casts` cannot be handled on SPIR-V backends (you cannot lower it to SPIR-V). We've discussed previously making it explicitly illegal to introduce shape_casts that arent strictly linearizing or all delinearizing.
> It is really something that cannot be handled in SPIR-V and as such should not be on the default path.

Can you please provide a link to the discussion so we can follow?
Additionally, related to strictly linearizing / delinearizing sounds like you want an interface.
How much of the SPIR-V quirks are explicitly captured upstream.
At the very least, this type of insights shoudl be captured in well-document invalid tests.

> Is there any way for us to check what's suitable for SPIR-V and what isn't? Otherwise we might be hitting similar issue with every single canonicalisation that we try (hypothetically). Ideally, there would be a test upstream that would start failing after moving this to the canonicalization pass.

strong +1

> As for whether this should be a canonicalization or not, I feel that we need more input.

Also +1, it seems SPIR-V and scalable vectors have enough quirks that we should think about better capturing legality for different backends.
It seems that between SPIR-V and scalable vectors, we have a lot of conflicting needs and constraints.
Things should be laid out in a common upstream place where they can be reasoned about together.


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