[Mlir-commits] [mlir] [mlir][vector] Refactor vector linearization patterns (PR #142685)

[James Newling]

newling wrote:

> > Yes, that's the main change. It's shown in a test in the end goal draft PR l #142672.
> 
> Did you mean `-test-vector-linearize=preference=Shuffle`?

Not quite, because the user doesn't choose exactly what patterns run there. I was thinking of the following: 

In the new file [TestVectorLinearize.cpp](https://github.com/llvm/llvm-project/pull/142672/files#diff-d29fda04a87b16dd4a715856d867857827831c4b12ca979d731389d756c64cd7) in #142672

there are 3 passes for testing patterns, the one which shows how a user can 'mix-and-match' is `TestRankReduceStridedSliceOps`. The relevant code there is 

```c++
 VectorLinearizePatterns()  // 1
        .enableAll(false) // 2
        .enable(LinearizePattern::RankReduceInsertStridedSlice) // 3
        .enable(LinearizePattern::RankReduceExtractStridedSlice) // 4
        .addToPatternSet(typeConverter, patterns); // 5
```

where 
(1) Initially all patterns are enabled (object of 'helper class' VectorLinearizePatterns default initialized)
(2) All patterns are disabled
(3) and (4) The 2 patterns 'the user' wants enabled are re-enabled
(5) we populate the mlir::RewritePatternSet from the helper class

As for the tests using preference (shuffle vs strided) like `-test-vector-linearize=preference=Shuffle`, they _could_ follow this design pattern, and the idea of 'preference' could be completely removed from the public API. It was a design choice to hide the details of what patterns get run in the 2 cases (happy to reconsider if/when we get to that PR)

I hope that makes a bit more sense!

FWIW I suppose this proposed change to expose more fine grained pattern control is related to the second point of the discourse thread https://discourse.llvm.org/t/finding-rewrite-patterns/85810

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