The result type of an ExpandShapeOp cannot be inferred from the source type and the reassociations. The result shape must be specified. Strides can be computed.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I just have a question here (looking through the code, but before I dig into more details). Is it even valid to reshape a memref with strides. The memref could be result of a subview, but if the subview is not itself of a contiguous region of memory, then the reshape is invalid (you cannot reshape any arbitrary subview). Apart from this the rest of looks fine.
mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td | ||
---|---|---|
1231 | Nit: Could we make the order resultShape, src, reassociation, attrs? This is consistent with the resulttype, operands, attrs scheme, except the result type is replaced with result shape. |
I think this is a problem only for collapse_shape, where two non-contiguous regions may be collapsed. I think that's what isReshapableDimBand is checking.
In the case of expand_shape, we split a dim into multiple dims, so just adding new strides/sizes. I think this can always be done without a copy. I'm still a bit confused about strides etc. (esp. when they are dynamic), so maybe I'm missing something here.
mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp | ||
---|---|---|
1494 | We've been moving away from AffineMap from reassociations. | |
1506 | do you need the full AffineExpr or can you use some of the saturated arith stuff ? | |
1516 | use ShapeType::isDynamic(idx), here and below plz. |
In the case of expand_shape, we split a dim into multiple dims, so just adding new strides/sizes. I think this can always be done without a copy. I'm still a bit confused about strides etc. (esp. when they are dynamic), so maybe I'm missing something here.
yeah, that makes sense. I tried a few examples, and couldnt find a counter-example to this. So by a totally unscientific method, this might be fine.
Maybe some lit-tests for the expanded_shape case with non-trivial strides would help catch bugs?
Nit: Could we make the order resultShape, src, reassociation, attrs? This is consistent with the resulttype, operands, attrs scheme, except the result type is replaced with result shape.