This is an archive of the discontinued LLVM Phabricator instance.

[mlir][tosa] align the type of padding and pad_const with the spec
AbandonedPublic

Authored by tatwaichong on Feb 4 2023, 2:03 AM.

Details

Summary

padding and pad_const are operands in the current implementation,
but in TOSA spec they are attributes.

Instead of being value agnostic operand type, switch these arguments
to static attribute type.

Change-Id: I529c8a1a0848627ead7950c7028a964977bf1497

Diff Detail

Event Timeline

tatwaichong created this revision.Feb 4 2023, 2:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2023, 2:03 AM
tatwaichong requested review of this revision.Feb 4 2023, 2:03 AM

update the patch title

Updating D143312: Summary:

padding and pad_const are operands in the current implementation,
but in TOSA spec they are attributes.

tatwaichong retitled this revision from Summary: padding and pad_const are operands in the current implementation, but in TOSA spec they are attributes. to [mlir][tosa] align the type of padding and pad_const with the spec.Feb 4 2023, 2:08 AM
tatwaichong edited the summary of this revision. (Show Details)
tatwaichong edited the summary of this revision. (Show Details)Feb 4 2023, 2:13 AM
tatwaichong added a reviewer: rsuderman.

I'm confused, I thought these were going the other way. E.g., there is a mismatch between what the spec calls an attribute and MLIR does, previously we had mostly err'd on treating them the same. But as the spec really requires this before execute/offload rather than representationaly , I thought the conclusion was that these should be operands and one had like a verify for export/runtime pass to flag that the operands are actually constants at that point.

Sorry for confusing you. I've not noticed there is a mismatch of attribute meaning between TOSA and MLIR. Could you explain a bit about the difference or why those arguments are better to be MLIR operands rather than MLIR attributes? I thought both attribute types are used to specify constant data on operations.
Alternative way without the pad definition changing, we're trying to add a section in a pass in MLIR to verify if the pad operands are constant in compile time. Any suggestions are welcome.

Sorry for confusing you. I've not noticed there is a mismatch of attribute meaning between TOSA and MLIR. Could you explain a bit about the difference or why those arguments are better to be MLIR operands rather than MLIR attributes? I thought both attribute types are used to specify constant data on operations.
Alternative way without the pad definition changing, we're trying to add a section in a pass in MLIR to verify if the pad operands are constant in compile time. Any suggestions are welcome.

It would make more sense to use an m_Constant check for validating that values expected to be constants are constants rather than changing a Value to an Attribute. Overall we should be moving away from Attributes towards Value based execution to have a better chance of supporting dynamically shaped models.

Thanks. Feedbacks from you guys are useful and constructive. Let me abandon this PR and go along the suggested way.

tatwaichong abandoned this revision.Feb 11 2023, 5:43 AM