This is an archive of the discontinued LLVM Phabricator instance.

[mlir] tosa.reshape - Add InferTensorType interface
ClosedPublic

Authored by AviadCo on Apr 16 2023, 11:46 PM.

Details

Summary

When this interface is used, a call to inferReturnTypeComponents()
is generated on creation and verification of the op.

Diff Detail

Event Timeline

AviadCo created this revision.Apr 16 2023, 11:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2023, 11:46 PM
AviadCo requested review of this revision.Apr 16 2023, 11:46 PM

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?

AviadCo edited the summary of this revision. (Show Details)Apr 17 2023, 12:45 AM
AviadCo added reviewers: jpienaar, mamrami.

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.

AviadCo added a comment.EditedApr 20 2023, 12:47 AM

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.

jpienaar accepted this revision.Apr 20 2023, 1:48 PM

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)

This revision is now accepted and ready to land.Apr 20 2023, 1:48 PM
AviadCo updated this revision to Diff 515651.Apr 21 2023, 2:06 AM

Refactored cast.

AviadCo marked an inline comment as done.Apr 21 2023, 2:08 AM
AviadCo added inline comments.
mlir/lib/Dialect/Tosa/IR/TosaOps.cpp
689

Good point, refactored.

AviadCo marked an inline comment as done.Apr 21 2023, 2:16 AM

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.

@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.

This revision was automatically updated to reflect the committed changes.