Cool; I ll adjust the RFC text tommorow.
--
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/23#issuecomment-909435339
Thanks @manupa-arm , P2 falls into the domain of the special memory tag, and
the storage scope is exactly designed for this purpose.
--
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/23#
Thanks @tqchen , yes we could work this for now.
I take it that for P2, we could use the tag of storage_scope as well, then ?
--
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/23#issueco
Thanks @manupa-arm I would suggest T2 to make things consistent with the rest
of IR design and allow future annotations if needed.
Note that annotation fields only offers hints to future passes(on how to
rewrite) and should not change the semantics of the IR
--
You are receiving this because
Hi All,
Thanks for taking the time to look at it.
Initially, my thoughts were to use the same field for two purposes :
P1) Indicate candidate memories (a.k.a. pools) that each allocate be associated
with
P2) After the memory planner is run, it will pick one out of the list by
reducing the candi
Thanks @junrushao1994.
--
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/7527#issuecomment-909129132
