When this interface is used, a call to inferReturnTypeComponents()
is generated on creation and verification of the op.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Why are we inferring the return type of reshape and thus require the new_shape attribute, instead of removing the new_shape attribute and just taking the return type as the type that we need to reshape to?
I believe as that matches the spec most directly. But it is a good question if required in dialect.
This change didn't change this, but if this was moved to being on the type, then inferReturnTypes couldn't be used anymore as there is not sufficient information in the op's operands or attributes to infer return type. Else I would say the above question doesn't affect this, but a change to the above would require a revert of this. So might be good to get verification about my above assumption/desirability of this here.
Well, removing new_shape is a big refactor which I think reuqires propare discussion if we would like to do so.
I also agree with @jpienaar's comment, but until we decide otherwise I think that infer shape can be useful and missing functionality to check element type of TOSA reshape operation.
We can raise a discussion to get ride of new_shape attribute and part of the work will be to revert this change.
Looks fine given this is existing matching.
mlir/lib/Dialect/Tosa/IR/TosaOps.cpp | ||
---|---|---|
689 | Nit: you can also use getElementTypeOrSelf(operands.getType()[0]) (new style also recommends cast<Foo>(x) rather than x.cast<Foo>() since that was added) |
mlir/lib/Dialect/Tosa/IR/TosaOps.cpp | ||
---|---|---|
689 | Good point, refactored. |
@jpienaar was right that new_shape was the most direct implementation of reshape from the TOSA specification to the dialect.
As long as the dialect can describe the functionality of TOSA reshape, I think we can have flexibility on the implementation. @AviadCo's plan to get this change merged, and separate out the removal of new_shape to a new thread seems reasonable.
Nit: you can also use getElementTypeOrSelf(operands.getType()[0])
(new style also recommends cast<Foo>(x) rather than x.cast<Foo>() since that was added)