The patch enables the use of index type in vectors. It is a prerequisite to support vectorization for indexed Linalg operations. This refactoring became possible due to the newly introduced data layout infrastructure. The data layout of a module defines the bitwidth of the index type needed to verify bitcasts and similar vector operations.
Can we add one integration test to see that everything works end to end?
e.g. in the same dir as this test: https://github.com/llvm/llvm-project/blob/main/mlir/test/Integration/Dialect/Vector/CPU/test-extract-strided-slice.mlir
LGTM otherwise after @ftynse comments on the data layout usage.
I would suggest adding a helper to find the closest parent that can have a data layout (either a ModuleOp or an op implementing DataLayoutOpInterface, whatever comes first). This can live on the DataLayout itself as a static method, static DataLayout DataLayout::closest(Operation *). I didn't have a need for this yet so I haven't added untested code.
In a slightly longer term, we would want to have a DataLayoutAnalysis that caches the results, and have verifier do this analysis only once.
Please update the .md docs accordingly. We still have a rationale that explains why we can't have vector<index> and a spec that contradicts this.
Addressing the following comments:
- added a simple end-to-end integration test
- updated the rational to reflect the index type support
- introduced a method to get the closest module or data layout op
There would be the option to use the closest method in the test-data-layout-query pass. Yet the code there also implements caching so I decided to not touch it.