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

[tatwaichong]

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

[tatwaichong]

update the patch title

Updating D143312: Summary:

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

[jpienaar]

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.

[tatwaichong]

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.

[rsuderman]

In D143312#4113508, @tatwaichong wrote:

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.

[tatwaichong]

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