You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tvm.apache.org by Manupa Karunaratne <no...@github.com.INVALID> on 2022/06/21 17:20:47 UTC
Re: [apache/tvm-rfcs] [RFC] Adding initial SVE implementation (#18)
Hi @tqchen @kparzysz-quic @kparzysz-quic @masahi @tkonolige @smeijer1234 ,
We are looking to revive this work. I have gone through the thread.
Summary so far is as follows :
* We want to introduce/enhance a scheduling vectorization primitive that could be controlled by user/auto-tuner/auto-scheduler either to use scalable vectors in the backend codegen.
* The conversation has resolved to be extending the existing vectorize scheduling primitive i.e. : s[C].vectorize(..., scalable=True)
* Usage of this scheduling primitive should result in creating a for loop with a Ramp nodes with either an additional argument "is_scalable" or special number for lanes.
* I think @tqchen was suggesting to use the special lane number (-1) as opposed to introducing an additional argument to all TIR nodes such as Ramp and Broadcast as well as DataType (and to DLDataType) to avoid ABI breakages.
* Moreover, VectorizeLoopScalable will be modified to create a While node.
* The name of the RFC is confusing ? @kparzysz-quic . I suppose for TIR, what we are adding is vector-length agnostic vectorization support for TIR, while demonstrating the codegen of VLA vectorized TIR using Arm(R) SVE codegen.
Please confirm whether this is a right summary of the current state.
As for next steps, I would like to propose/resolve each of the outstanding discussion points and update the RFC.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#issuecomment-1162041631
You are receiving this because you are subscribed to this thread.
Message ID: <ap...@github.com>