Regarding the changes required to support scalability in the data type, I've been prototyping adding a new `scalable_` attribute to `DataType` that wraps `DLDataType`.
However, I've ran into what I believe is an issue when accessing data types at compile-time across the FFI boundary between python and c++. `TVMArgValue` and `TVMRetValue` may have a value stored as a `DLDataType`. Storing a scalable `DataType` as a `DLDataType` will mean that we lose information about the scalability (assuming we don't want to alter DLPack, or use the negative lanes < -1 approach). For the limited number of test cases I've written, I've worked around this limitation by forcing `DataType` to be stored as a string across the boundary. But this feels a bit wrong. I wonder if there could be something I've missed here or if there are any other suggestions? Are there any rules for using `string`, `DataType` and `DLDataType` interchangeably? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1779468180 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/104/c1779468...@github.com>
