[Mlir-commits] [mlir] [mlir][vector] Support multi-dimensional vectors in VectorFromElementsLowering (PR #151175)

[Diego Caballero]

dcaballe wrote:

> What's more, after CSE, the unrolling method will have a much shorter length, because there are only 11 unique constant ops for indices.

Unrolling would generate 11-element vectors, which is a number the backend would have to legalize with padding or other techniques. We would have to look into the specifics of the example to understand what is happening but, in any case, my point was that we need to support both approaches. This shouldn't about using one vs the other.

```
I don't agree with "vector shuffles will be generated anyways by LLVM..."
```

The example only shows elementwise operations. For cases requiring actual shape/layout transformations, shuffles (or similar ops) would be needed, right? That was the point I was trying to make.

> Could you please further elaborate on what "using the direct implementation" refers to? My plan is to implement one following the example of [UnrollVectorGather](https://github.com/llvm/llvm-project/blob/5bd39a0060bed29e04db954eff77386473d38bb3/mlir/lib/Dialect/Vector/Transforms/LowerVectorGather.cpp#L52-L95).

For the vector linearization approach, we would need to add a pattern to [VectorLinearize.cpp](https://github.com/llvm/llvm-project/blob/f12e0380be3bd6084ae860090dc027e0281e388e/mlir/lib/Dialect/Vector/Transforms/VectorLinearize.cpp#L502) that is turning the n-D `vector.from_elements` op into a 1-D `vector.from_elements` op + `vector.shape_cast`.

For the vector unrolling approach, doing something like the vector gather example makes sense. The direct implementation refers to implementing the unrolling manually, using `vector.insert`/`vector.extract` operations.


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