[Mlir-commits] [mlir] [mlir][vector] Adds ToElementsToTargetShape pattern. (PR #166476)

[Erick Ochoa Lopez]

================
@@ -1013,14 +1113,15 @@ void mlir::vector::populateVectorUnrollPatterns(
                UnrollReductionPattern, UnrollMultiReductionPattern,
                UnrollTransposePattern, UnrollGatherPattern, UnrollLoadPattern,
                UnrollStorePattern, UnrollBroadcastPattern, UnrollFromElements,
-               UnrollToElements, UnrollStepPattern>(patterns.getContext(),
-                                                    options, benefit);
+               UnrollToElements, UnrollStepPattern, ToElementsToTargetShape>(
----------------
amd-eochoalo wrote:

There is already an UnrollToElements pattern. I prefer small simple patterns over larger ones. I'll turn this back to a draft for the time being.

I'm thinking about maybe moving this pattern somewhere else. While working on adding the analogous to `FromElementsOp` I found that there's an issue. The issue is that I was attempting to break down FromElementsOp into multiple FromElementsOp with a suitable vector length and then reconstruct the target type with InsertOp, but the canonicalize reverts this.

This only happens when the targetShape is {1} which can happen when the native vectors are of a size without a common denominator with the one in the source. For example, the native vector size is 4 and the vector in the IR is `vector<5xf32>` then the current `getTargetShape` will suggest rewriting it to 5 `vector<1xf32>`.

This I believe comes from:

```cxx
int mlir::spirv::getComputeVectorSize(int64_t size) {
  for (int i : {4, 3, 2}) {
    if (size % i == 0)
      return i;
  }
  return 1;
}
```

When I go around this issue, I get `builtin.unrealized_conversion_cast`s.

I'm still thinking about whether there is another option. (For example, replace `vector<5xf32>` with two `vector<4xf32>` and then extract what's needed from the other one.

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