Re: [apache/tvm-rfcs] [RFC] Scalable vectors in TIR (PR #104)
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 predication goes, you're right---it's somewhat independent from SVE. To take full advantage of SVE we'd need to be able to vectorize loops with iteration count that is not known at compile time, which is the part I'm interested in. Are you planning to implement that in the near future, or is this a longer-term goal? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1755456586 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/tvm-rfcs] [RFC] Scalable vectors in TIR (PR #104)
> 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? `` 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:
Re: [apache/tvm-rfcs] [RFC] Scalable vectors in TIR (PR #104)
> 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 accepting or returning a value of that type, and will affect the memory layout of a DLTensor (and likely more). As a consequence, code build with older TVM will not be compatible with that built with a newer TVM, plus it will have an impact on any other project using dlpack. Changing it is not impossible, but we should be careful about it. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1755730601 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/tvm-rfcs] [RFC] Scalable vectors in TIR (PR #104)
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 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. This would be analogous to the distinction between the runtime `DLTensor` and the compile-time `tir::Buffer`. It would still involve massive changes inside of TVM, but would preserve the runtime types, avoiding the ABI breakage of compiled functions. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1755890786 You are receiving this because you are subscribed to this thread. Message ID:
