[Encoding] Introduce EncodingLayoutAttrInterface. #19216
Conversation
The revisions introduces a new attribute interface in the Encoding dialect. The interface is used to query layout information needed to materialize encoding attributes. Any backend can implement the interface to interpret an encoding layout based on their needs. The current expectation of the interface is to propagate layout information from backends to the host compliation or other targets. The expectation can be adjusted as long as we identify additional needs for encodings/layouts. It is a step towards iree-org#17924 Signed-off-by: hanhanW <[email protected]>
| ), | ||
| /*methodBody=*/"", | ||
| /*defaultImplementation=*/[{ | ||
| return {}; |
There was a problem hiding this comment.
Would it be better to insert an assert to fail here? I assume it must be re-implemented by whoever inherits the interface.
There was a problem hiding this comment.
We could do it. The other way to think about it is that the caller can check if the return value is nullptr or not; raise the error with proper messages. Adding an assertion is being careful to me, while it could add confusion to users because the error messages and stack dump are all bad. Both work for me because we do not have a working case today..
There was a problem hiding this comment.
As a user I would definitely prefer not to check null every time I call this function, if such API call guarantees that it will definitely return something sensible other than nullptr.
The revisions introduces a new attribute interface in the Encoding dialect. The interface is used to query layout information needed to materialize encoding attributes.
Any backend can implement the interface to interpret an encoding layout based on their needs.
The current expectation of the interface is to propagate layout information from backends to the host compilation or other targets. The expectation can be adjusted as long as we identify additional needs for encodings/layouts.
It is a step towards #17924