P1: Graph partitioner for CMSIS-NN target
P2: Code generation using existing BYOC
P3: tvmc support to generate code for CMSIS-NN
P4: Move this implementation using `tir_to_runtime` from target hooks
P5: Use of CMSIS-NN data structures while supporting depthwise convolution
P6: Support for Convoluti
Hi @jroesch @Mousius ,
I think having Pass'es (instead of functions) could also work.
I guess what we are after is the ability to assemble and re-use TVM's
compilation passes on a target basis.
https://github.com/apache/tvm/pull/8110#discussion_r639559530
Continuing the above comment, this also
Merged #8 into main.
--
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/8#event-5111983679
This is a tracking issue to implement [RFC 8: Project
API](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0008-microtvm-project-api.md).
See the RFC and discuss forum for more details.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view i
duplicate of #8595
--
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/8654#issuecomment-892757435
Closed #8654.
--
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/8654#event-5112007211
Hi all,
After some discussion, we'd like to propose that RFCs are numbered
according to the GitHub PR number. This follows the idea of documenting those
RFCs which are rejected. While it adds an extra step to the initial RFC
posting, it simplifies all future references by not allocating two dif
I like the idea. It follows the common practice in previous communities and
simplifies the RFC process.
--
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/17#issuecomment-892770698
Introducing the addition of Arm Architecture's Scalable Vector Extension
(SVE) in TVM containing initial VLA and predication implementation, based on
earlier work by Giuseppe Rossini.
@mbaret
You can view, comment on, or merge this pull request online at:
https://github.com/apache/tvm-rfcs/p
Yes we can udpdate the merged RFC, the only one I am aware of is autoTIR RFC
and perhaps @junrushao1994 can chime in
--
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/17#issuecomment-892
Going to get to this tomorrow 😬. Promise 🤞
--
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/6#issuecomment-893004650
btw, according to #17, please update the RFC number on the file name to align
with this PR number.
--
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/6#issuecomment-893007973
I think it is a good idea to invite people working on RISC-V support for TVM,
since the RISC V vector extension is similar to ARM SVE. I remember some people
in Taiwan are working on this. Maybe @comaniac knows who?
--
You are receiving this because you are subscribed to this thread.
Reply to
> I think it is a good idea to invite people working on RISC-V support for TVM
> for review/discuss, since the RISC V vector extension is similar to ARM SVE.
> I remember some people in Taiwan are working on this. Maybe @comaniac knows
> who?
Thanks for bringing up. cc @yrchen
--
You are rec
14 matches
Mail list logo
