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>