Thank you @giuseros for your answer, it looked good to me. Just to add on, we
know which loops need to be legalised as in TIR we do add a new `ForKind`
called `kVectorizedScalable` (cc @tkonolige) which marks the loop as able to be
vectorized but the value of VL is unknown. These loops are then
Thank you all for the comments so far, we are currently working on a response
to address them.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#issuecomment-894160941
@jroesch are there plans to include AOT in this now?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/7526#issuecomment-894187809
Thanks @MeeraN7 . I think the overall loop legalization makes sense. I wonder
then if it is necessary to update the node construct such as Ramp, or can we
directly make use of scalar loop in the body
--
You are receiving this because you are subscribed to this thread.
Reply to this email direct
Would be great to update the RFC naming per
https://github.com/apache/tvm-rfcs/pull/17. cc @comaniac @zhiics who might have
some insights from BYOC and @echuraev who might draw some parallels from Apple
lib integration
--
You are receiving this because you are subscribed to this thread.
Reply
@Mousius thanks for this RFC and apologies for the long delay. I read this in
conjunction with [[RFC] Arm® Ethos™-U
Integration](https://discuss.tvm.apache.org/t/rfc-arm-ethos-u-integration/10504)
to try to understand the initial application. I think that should be a
sufficient example, but l
