ekalda commented on PR #104: URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1757833764
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
