[Mlir-commits] [mlir] [mlir][vector] Patterns to convert to shape_cast, where possible (PR #138777)

[Diego Caballero]

dcaballe wrote:

Thanks for sharing your thoughts! Replying to this and [this](https://github.com/llvm/llvm-project/pull/139819) threads here. 

 

I think part of the challenge with canonicalization stems from the expectations we’ve built around it. We often assume the IR after canonicalization will be ideal for all patterns, analyses and, ultimately, lead to the most efficient lowering/ASM/runtime performance and whatnot. But realistically, canonicalization should only focus on eliminating redundancy from the IR and offering a unique and consistent representation to make passes consuming such a canonical form simpler, regardless of everything else. For me, a pass running on canonical IR that must deal with both: 

```
%0 = vector.broadcast %arg0 : vector<4xi8> to vector<1x1x4xi8> 

```
and 

```
%0 = vector.shape_cast %arg0 : vector<4xi8> to vector<1x1x4xi8> 

```
indicates that we have a gap in the canonical form because both operations are representing the same thing. 

 

IMO, using `vector.shape_cast` to handle reshape- or view-like operations that don’t involve data rearrangement/movement (at least at this specific virtual vector level) simplifies things significantly, especially compared to heavier operations like transposes. Later, during legalization, a `vector.shape_cast` may have to be handled differently depending on the specific target, backend compiler or even lowering approach (e.g., legalizing to multi-dim vectors, linearizing multi-dim vectors, unrolling multi-dim vectors...). That is expected but it shouldn’t prevent us from using it as part of the canonical form of the Vector dialect if it brings value at that level. Improving its lowering to LLVM for cases where it’s really needed should be within the expected work that we have to do.

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