Thanks for bringing up. this is also very useful on RISC-V. we look forward to
progress in this regard.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#issuecomment-1171880247
You are receiving this because you are subscribed to this thread.
Me
Built docs for commit 28d0ba9ba7f7353789fb608880b833087491e3fd can be found
[here](https://pr-docs.tlcpack.ai/PR-11938/2/docs/index.html).
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/11938#issuecomment-1171730426
You are receiving this because you a
@manupa-arm i think your summary is roughly correct.
@tqchen @masahi @kparzysz-quic perhaps you guys could have a look and see if we
could resolve the question of how to represent the scalable concept in
DLDataType. also cc @alter-xp in case they would like to leverage this for
RISC-V (i'm awar
cherry pick: #11969
reason: needed to get tests on the Python wheel in GitHub Actions passing
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/11736#issuecomment-1171615115
You are receiving this because you are subscribed to this thread.
Message ID:
A couple of thoughts...
- We should have a common facility that represents a scope in which names need
to be unique. Conceptually it could be a set of "known" strings (that are
presumed used), and something (like a private counter) to generate a unique
suffix. The use would be `new_name = Gen
cc @mbs-octoml @Mousius @manupa-arm @MichaelJKlaiber @grant-arm @kparzysz-quic
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1171465597
You are receiving this because you are subscribed to this thread.
Message ID:
> In general it is helpful to first keep schedule decision local, e.g.
> introducing a caching stage (AC, BC in the example), the compose with another
> reflowing pass to bring the decision to consumer/producers.
My goal with the latest update wasn't to require global decisions, but to make
loc
> Thanks @gigiblender ! a few points for consideration:
>
> * Ideally NameSupply should interact well with our current linkage spec,
> e.g. if a function have an attribute `global_symbol`, it means the name is
> "final"(because external users are expecting to look it up with that name),
> l
