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

[James Newling]

newling wrote:

> Hey, thanks for bringing this up! Could you elaborate a bit more on the final state you are working towards? Why do we need such a finer grain level of optionality for these patterns?

The final state I'm working towards is basically this PR plus 4 additional patterns. These are 4 patterns for linearizing towards insert_strided_slice and extract_strided_slice, instead of towards shuffle (see for example VectorExtractToRankOneStrided in https://github.com/llvm/llvm-project/pull/142672). The motivation for linearizing this way is that the strided ops are 'higher' level than shuffle, because they retain the fact that the extract/insert is contiguous. This alternative lowering isn't a 'must have' for linearization in general, but it was my preferred linearization and what I had before trying to integrate with upstream. 

I could add these 4 patterns without exposing all the patterns in a public API. That would entail adding just 1 new API for this alternative lowering. Perhaps I should post a series of smaller separate PRs with those new patterns. My motivation for the fine grained control was mostly a personal preference, and not seeing an obvious partition of the patterns (as mentioned in this PR summary). I have been in situations using upstream patterns before where I wanted only a subset of the patterns added by the public APIs... But I know that consistency in Vector is worth a lot. so am happy to not go with this fine grained approach :)

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