You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tvm.apache.org by "kparzysz-quic (via GitHub)" <gi...@apache.org> on 2023/09/04 17:03:43 UTC

[GitHub] [tvm-rfcs] kparzysz-quic commented on pull request #104: [RFC] Scalable vectors in TIR

kparzysz-quic commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1705543104

   Thanks for bringing this up again.
   
   A few suggestions to make it more general:
   1. Add a parameter to `tir.vscale` to state the minimal assumed vector length.  For AArch64 SVE it will be 128 (bits), but some other non-SVE architecture can provide a different value (via a target hook, or something like that).  This way more targets can take advantage of this.
   2. The special case of `lanes == -1` in Ramp does not easily extend to multiple parameters, but it could be handled in some ways...
   3. If you plan to include predication eventually, that would be something that a lot of targets could use.  The LLVM intrinsics for predicated operations do not explicitly require SVE, they can be used with fixed-sized vectors as well.
   
   For dealing with an unknown vector lengths and simultaneously allowing specific lengths per use-site we could either
   1. Require that if Ramp/Broadcast has `lanes == -1`, then the `base`/`value` member must be a TIR intrinsic specifying the vscale for the value.  E.g. `Ramp(tir.vscale(128, base), stride, -1)` or `Broadcast(tir.vscale(256, value), -1)`.
   2. Extend Ramp and Broadcast to take `lanes` as `PrimExpr`, with restrictions on what that expression can contain.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org