I guess we could pass an argument to the vectorizer whether to generate
SVE-friendly code. If this is limited to emitting additional TIR builtins,
then I'm ok with that. I just want to be able to reuse as much of the
vectorization code as possible between SVE and non-SVE targets.
As far as pr
> 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 spe
> 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?
DLDataType comes from dlpack not TVM. Changing it may affect the ABI of any
function acceptin
Agreeing with @kparzysz-quic, changes that update the `DLDataType` would need
to be approached very cautiously. I usually lean toward allowing short-term
breakages if they lead to better long-term code health, but updating the
`DLDataType` would be very wide reaching even more my tastes.
One
