Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
2035 | There is also a restriction on the number of elements, if known, right? | |
2038 | nit: ranked or ranked? | |
2052 | nit: here too. | |
mlir/lib/Dialect/StandardOps/IR/Ops.cpp | ||
2152 | You have extraClassDeclaration so why not move this there, too? | |
2173 | Is this tested somewhere? |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
2038 | Nit: s/length/size | |
2043–2044 | I'm not sure why we need this version. The shape of the result is known from the type, so this is essentially asserting that the shape argument contains the same values as the result type. | |
2072 | We don't do OpBuilder, OperationState here anymore. | |
2084–2085 | Nit: would functional-type(operands, results) work here? |
Address the comments.
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
2035 | Right. In the design doc @ftynse had the idea of having a separate pass that would add std.asserts to ensure the same number of elements. | |
2043–2044 | I am not sure what you mean here. Do you mean that there is no need to print the shape if the result is statically-shaped and %shape is const? We need a case when the shape arg is non-constant. I'll add some examples. | |
2072 | that's much nicer |
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
---|---|---|
2043–2044 | I guess the idea would be to drop the shape operand if it is static anyway. That would give us a static and dynamic version of this operation. Could be worthwhile, especially as we otherwise have to allocate a memref with static contents. I'd say we start with the most general form and can add refinements later if they turn out to be useful. |
There is also a restriction on the number of elements, if known, right?