> Another idea to handle this would be to add a new field to DLDataType, e.g. > bool is_scalable, but I'm not sure how feasible changing that standard is.
I feel extending DLDataType to represent scalable vectors explicitly would be a more robust design than depending on interpreting -1 in a special way for the lane parameter. Is there any technical reason blocking us from extending DLDataType to have a `is_scalable` vector field, allowing us to maintain the meaning of the lanes field to represent the number of lanes? `<vscale*4*float>` can then be encoded by setting the `is_scalable` field and setting the `lane` field to 8 and we do not need to introduce any special handling. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1755692891 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/104/c1755692...@github.com>
