e9e25f02e6
This patch enforces a restriction in the Vector dialect: the non-indexed operands of `vector.insert` and `vector.extract` must no longer be 0-D vectors. In other words, rank-0 vector types like `vector<f32>` are disallowed as the source or result. EXAMPLES -------- The following are now **illegal** (note the use of `vector<f32>`): ```mlir %0 = vector.insert %v, %dst[0, 0] : vector<f32> into vector<2x2xf32> %1 = vector.extract %src[0, 0] : vector<f32> from vector<2x2xf32> ``` Instead, use scalars as the source and result types: ```mlir %0 = vector.insert %v, %dst[0, 0] : f32 into vector<2x2xf32> %1 = vector.extract %src[0, 0] : f32 from vector<2x2xf32> ``` Note, this change serves three goals. These are summarised below. ## 1. REDUCED AMBIGUITY By enforcing scalar-only semantics when the result (`vector.extract`) or source (`vector.insert`) are rank-0, we eliminate ambiguity in interpretation. Prior to this patch, both `f32` and `vector<f32>` were accepted. ## 2. MATCH IMPLEMENTATION TO DOCUMENTATION The current behaviour contradicts the documented intent. For example, `vector.extract` states: > Degenerates to an element type if n-k is zero. This patch enforces that intent in code. ## 3. ENSURE SYMMETRY BETWEEN INSERT AND EXTRACT With the stricter semantics in place, it’s natural and consistent to make `vector.insert` behave symmetrically to `vector.extract`, i.e., degenerate the source type to a scalar when n = 0. NOTES FOR REVIEWERS ------------------- 1. Main change is in "VectorOps.cpp", where stricter type checks are implemented. 2. Test updates in "invalid.mlir" and "ops.mlir" are minor cleanups to remove now-illegal examples. 2. Lowering changes in "VectorToSCF.cpp" are the main trade-off: we now require an additional `vector.extract` when a preceding `vector.transfer_read` generates a rank-0 vector. RELATED RFC ----------- * https://discourse.llvm.org/t/rfc-should-we-restrict-the-usage-of-0-d-vectors-in-the-vector-dialect
69 KiB
69 KiB