Regarding to changing the `DLDataType`, I can see how it could have a wide disruptive impact. Scalable vectors are here to stay though, so could be a way to future proof `DLPack` standard? 🤷♀️
One of the main problems we have with using -1 to denote scalable vectors is that it doesn't capture all information. E.g. if we want to set the `lanes` of the `Ramp` to `8 * vscale()` (or `vscale(8)`), what's the `lanes` in `DataType`/`DLDataType` going to be? 1. **-1**: it's impossible to recover from this what was the "multiplier" (in this example 8), so runtime data type does not have all the information. Quite a lot of the stack (especially codegen) relies on checking the lanes from the `DataType` object. 2. **-8**: captures all the information, but we think it's awful 🙈 > One way to limit the scope of the change might be to introduce a distinction > between the runtime DLDataType, and some new compile-time data-type. How do you feel about extending `tvm::runtime::DataType` to hold some information about the scalability? From what I can see, it is just a wrapper around `DLDataType` plus some helper functions. We could add a field there to indicate if it is scalable vector. How disruptive would that be? I suppose we'd have the problem of the `DLDataType` not holding the information about the scalability, but I'm not sure if that would be very important. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1757833764 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/104/c1757833...@github.com>
