Based on discourse discussion, fix the doc string and remove examples with wrong semantic. Also fix insert_map semantic by adding missing operand for vector we are inserting into.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks Thomas, this is a better separation of op semantics from transformation considerations indeed!
mlir/include/mlir/Dialect/Vector/VectorOps.td | ||
---|---|---|
463–464 | Actually let's simplify this too: Takes an 1-D vector and extract a sub-part of the vector starting at `id` with a size of `vector size / multiplicity`. No need to speculate on all the things that %id will represent in the op definition. | |
691–692 | Same here please. Thanks! |
mlir/include/mlir/Dialect/Vector/VectorOps.td | ||
---|---|---|
463–464 | nit: Takes ... and extracts (same verb form) |
mlir/include/mlir/Dialect/Vector/VectorOps.td | ||
---|---|---|
717 | Note this is missing the vector to insert into. %n = constant dense<x> : vector<4xi32> %3 = vector.insert_map %1, %n[%idx0: 2] : vector<2xi32> to vector<4xi32> |
mlir/include/mlir/Dialect/Vector/VectorOps.td | ||
---|---|---|
717 | Makes sense, I think that was the key missing part. |
mlir/include/mlir/Dialect/Vector/VectorOps.td | ||
---|---|---|
717 | Ah that changes quite the picture! But why do we need a multiplicity attribute now? We have the type of the vector we insert into: don't we need only the index? |
mlir/include/mlir/Dialect/Vector/VectorOps.td | ||
---|---|---|
717 | Good point, this is redundant right now. I think there was some ideas behind it to be able to handle non aligned cases but this is definitely premature at this point. Removing it to make things clearer for now. |
Could we also expand the doc for these op to explain how they differ from vector.insert and vector.extract?
mlir/include/mlir/Dialect/Vector/VectorOps.td | ||
---|---|---|
719 | Sorry I mistyped, can we s/to/into to be more consistent with other vector ops? |
Actually let's simplify this too:
No need to speculate on all the things that %id will represent in the op definition.
This makes it more in line with the LLVM boundary case: https://llvm.org/docs/LangRef.html#extractelement-instruction.