Re: [apache/tvm] Fix Cython compile for v3.0.0 release (PR #15346)

My guess would be that because the Conda build uses `3.7` of Python, it isn't receiving newer builds of Cython. https://github.com/apache/tvm/blob/e2d65111616dfa95797c0dd7e082e4050b71701d/conda/build-environment.yaml#L28 That may be quite concerning given `3.7` just passed end of life (https://

Re: [apache/tvm] [VOTE] Establish TVM Unity Connection Technical Strategy (Issue #12651)

0 Does this vote serve any purpose given the `unity` work is continuing regardless of the outcome? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/12651#issuecomment-1422361628 You are receiving this because you commented. Message ID:

Re: [apache/tvm-rfcs] [RFC] Further Unify Packed and Object in TVM Runtime (PR #97)

@tqchen Ack. I'll take another look this week. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/97#issuecomment-1418746047 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

@tqchen RFC rejected 😸 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1375932226 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Closed #96. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#event-8183713990 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> It will however, come with benefit of clarity for broader TVM communty > members who are interested in Bx but not in B, or both in (Bx-B) and B. As a > result the requested change, which i believe would be net positive for > developer users both in (Bx - B) and B. They are pretty actionable wi

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> The suggestions are made on that basis not only considering embedded C and > rust API(we should of course take that into consideration as part of the > process like you suggested), but also general TVM project(and broader tvm > community) as a whole for this specific context of rust language i

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> I also stated reasonings on why the interface_c name was a OK choice under > that the context of C, because C is a language that is mostly used for > embedded space -- rust do not have that same profile, as a result when we do > the development we need to consider it under the new context of r

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

I'd suggest your concerns might be better raised alongside https://discuss.tvm.apache.org/t/pre-rfc-api-change-formalizing-c-backend-api/10380 :smile_cat: -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1373406483 You are receiving

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> To incorporate that suggestion, this can be done through say > > * On compilation part, have proper namespace, file or folder structure to > indicate the grouping (that we are looking at embedded rust) so to avoid > confusion with other rust APIs. > * (a) introducing a new namespace; (b) use a

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> I am only referring to the clarifying the module with proper namespace, > folder structure and naming convention helps to bring the clarity to > developers and users as they start to interact with the APIs. > > For example, putting some of the API under `micro` namespace(actually any > namesp

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

I acknowledge your concerns @tqchen, the diversity of API in TVM is a problem beyond this RFC though. This RFC is aligned with the Embedded C APIs, which have a multitude of examples within the TVM repo. If we want to re-scope the embedded interfaces then I'd suggest we do that in a separate R

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

New APIs are now documented and I've raised https://github.com/apache/tvm/issues/13705 😸 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-137596 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Heads up, we're working on an iteration on this RFC with more idiomatic Rust 😸 though anyone willing to take a first pass would be appreciated still. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1344537878 You are receiving this be

Re: [apache/tvm] [skip ci] Revert "[ci] Protect release branches (#13208)" (PR #13274)

Merged #13274 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/pull/13274#event-7730461086 You are receiving this because you are subscribed to this thread. Message ID:

[apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Co-authored-by: Ashutosh Parkhi You can view, comment on, or merge this pull request online at: https://github.com/apache/tvm-rfcs/pull/96 -- Commit Summary -- * Embedded Rust API RFC -- File Changes -- A rfcs/0094-embedded-rust-interface-api.md (275) -- Patc

Re: [apache/tvm-rfcs] [RFC] Relax Upstreaming (PR #89)

> @Mousius In this case, @YuchenJin 's reply clearly articulated that there is > a close co-design of these factors, and changing to adopt dynamic alone would > imply a one-step jump to relax -- which is not incremental. The data > structure change would come with a set of supporting infra and c

Re: [apache/tvm] [VOTE] Issue Triage Workflow RFC (Issue #12743)

+1 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/12743#issuecomment-1241615153 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

@kparzysz-quic, sorry, I'm still not understanding here - the name of the kind is enough to look it up in the kind registry and gather any kind-specific information. What further details are missing? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/

Re: [apache/tvm-rfcs] Add Target Features RFC (PR #78)

> If we add another member to `Target`, how will this interact with the [target > parser proposal](https://github.com/apache/tvm-rfcs/pull/71)? The hope is to use the target parser to parse out the features as it'd just be an additional field we can set: ```c++ target_json.Set("features", featu

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

> Actually, the target JSON only shows the name of the kind, so the target > parser (if it operates on the JSON) won't see the details of the kind, unless > they are included in the JSON. I think that expanding the contents of the > target JSON to contain the kind specifics as well is critical f

Re: [apache/tvm] [VOTE] Release Apache TVM v0.9.0.rc0 (Issue #12103)

+1 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/12103#issuecomment-1185493250 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm] [release] v0.9.0 Release Schedule (Issue #11736)

@driazati / @areusch are we pushing the release schedule for #12022 ? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/11736#issuecomment-1184613371 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Add Target Features RFC (PR #78)

> @Mousius added a question. would you like to discuss at a Community Meeting? Happy to do a quick update on where this went 😸 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/78#issuecomment-1170073609 You are receiving this because you are subscrib

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

@areusch I replied to your comments, could you take a look and see if it makes more sense to you? Then if we're all happy I'll do a final update on the text 😸 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/71#issuecomment-1167403744 You are receivi

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

In the spirit of keeping this simple to review, the text of this RFC has been reformulated to cover the `target_parser` replacement for `preprocessor` which @junrushao1994 proposed - I've raised a follow on for the `features` additional to the `Target` so that can also be reviewed in isolation w

[apache/tvm-rfcs] Add Target Features RFC (PR #78)

You can view, comment on, or merge this pull request online at: https://github.com/apache/tvm-rfcs/pull/78 -- Commit Summary -- * Add Target Features RFC -- File Changes -- A rfcs/0078-target-features.md (178) -- Patch Links -- https://github.com/apache/tvm-rfcs/pull/78.patch https:

Re: [apache/tvm-rfcs] [RFC] A proposed update to the Docker images ci_* tag pattern (PR #66)

> > @leandron, looking at Docker Hub (https://hub.docker.com/_/hello-world) it > > would appear the convention for image names is to use `-` there as well > > (i.e. `tlcpack/ci-cpu` rather than `tlcpack/ci_cpu`) can we go for that one? > > Sure. I’ll push an updated version with this and @gromer

Re: [apache/tvm-rfcs] [RFC] Relay Next Roadmap (PR #69)

Merged #69 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/69#event-6662507785 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

Hi @junrushao1994, thanks for the elaborate reply 😸 I don't want to debate our personal principles but I appreciate you sharing them and will reference them where I can. > **Current `arch`-specifc checks.** Most of the 6 groups of `arch`-specific > helper functions, mentioned in the "Motivatio

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

> I like it overall, though I do have one potential concern: By making it > easier to query the architecture compared to cross-architecture features, > will developers more often use architecture-specific checks that > unnecessarily limit TVM features to specific architectures? Unfortunately, t

Re: [apache/tvm-rfcs] [RFC] Relay Next Roadmap (PR #69)

> Thanks folks for discussions. Just want to chime in here. I think we all > agree that the development and upstreaming flow should closely follow the > normal process, which is A2 as being listed by @denise-k . > To put it in another way, that the roadmap is independent from what/how > things a

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

> I think this is generally ok. I suggest elaborating a bit more in the text of > the RFC that the preprocessors apply to the target kind, and that for all > architectures, the code specific to each architecture would need to be > handled as a part of the common preprocessor. The use of names li

Re: [apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

> Thanks @Mousius . Given these fields are pretty relevant to compiler > configurations in traditional domain, it would be nice to also discuss prior > approaches(e.g. where those fields normally sits in say LLVM) for posterity. > This would also help us to make meaningful choices that aligns wi

Re: [apache/tvm-rfcs] [RFC] Quarterly Releases (PR #67)

> @Mousius that's my suggestion. i don't know who should do it--perhaps at > least the nominated person is responsible for finding someone to do it and > ensuring it's done? I'd suggest we make it clear it may be required when taking the role, but equally if they find someone to swap with then

Re: [apache/tvm-rfcs] [RFC] Quarterly Releases (PR #67)

> my vote is the following (for now, we can revisit at 1.0): > > * we agree we will fix major bugs on `0.X.Y` where `0.X.Y` is the latest > release. > * when we make a new minor version release e.g. `0.(X+1).0`, we will stop > maintaining releases starting with `0.X.` at that time. > * committer

[apache/tvm-rfcs] Add Target Pre-processing RFC (PR #71)

You can view, comment on, or merge this pull request online at: https://github.com/apache/tvm-rfcs/pull/71 -- Commit Summary -- * Add Target Pre-processing RFC -- File Changes -- A rfcs/0070-target-preprocessing.md (208) -- Patch Links -- https://github.com/apache/tvm-rfcs/pull/71.p

Re: [apache/tvm-rfcs] Inclusive Language RFC (#68) (PR #68)

Great work @grant-arm, a very positive initiative! -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/68#issuecomment-1123505773 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Inclusive Language RFC (#68) (PR #68)

Merged #68 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/68#event-6588785727 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] [RFC] Relay Next Roadmap (PR #69)

> If I'm interpreting your message correctly, your concern is that Relax's > current approach towards development does not yet utilize any of these task > tracking mechanisms. Apologies, I'll clarify, there is no need for Relax to use any of TVMs development process, as it's an exploratory proj

Re: [apache/tvm] [ETHOSN] Roll CI forward to Ethos(TM)-N release 21.11 (PR #11099)

Can you raise a Docker update issue to get this into `ci_cpu` @Leo-arm ? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/pull/11099#issuecomment-1108713581 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm] [ETHOSN] Roll CI forward to Ethos(TM)-N release 21.11 (PR #11099)

Merged #11099 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/pull/11099#event-6491414237 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm] [ETHOSN] Roll CI forward to Ethos(TM)-N release 21.11 (PR #11099)

Thanks for the update @Leo-arm! -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/pull/11099#issuecomment-1108711815 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] [RFC] A proposed update to the Docker images ci_* tag pattern (PR #66)

@leandron, looking at Docker Hub (https://hub.docker.com/_/hello-world) it would appear the convention for image names is to use `-` there as well (i.e. `tlcpack/ci-cpu` rather than `tlcpack/ci_cpu`) can we go for that one? -- Reply to this email directly or view it on GitHub: https://github.c

[Apache TVM Discuss] [Development/pre-RFC] [RFC] Allow merging via PR comments

Hi @driazati, I think this is a great improvement to help empower more people to contribute without having to synchronise with those with certain powers in the project across many timezones and organisations, as well as providing some much needed consistency on commit messages. Could this imp

Re: [apache/tvm-rfcs] @slow test RFC (PR #55)

Merged #55 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/55#event-6033032489 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] [RFC][Roadmap] TVM Continuous Integration & Testing Roadmap (PR #54)

Merged #54 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/54#event-6033018851 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] [RFC][Roadmap] TVM Continuous Integration & Testing Roadmap (PR #54)

@areusch helped me understand the contention here, there's a release process for managing things such as bugs, security vulnerabilities and other forms of fixes in a release cycle and accounting for all of those things in this roadmap is definitely out of scope :smile_cat: My confusion was tha

Re: [apache/tvm-rfcs] [RFC][Roadmap] TVM Continuous Integration & Testing Roadmap (PR #54)

> @leandron @Mousius thanks for taking a look! @denise-k updated the RFC to > address and scope security. I agree this is important. I think this covers > the bit you're mentioning about CI security; I think given the themes of the > roadmap, TVM security should fall more into a "release-oriente

Re: [apache/tvm-rfcs] [RFC][Roadmap] TVM Continuous Integration & Testing Roadmap (PR #54)

As an extension of @leandron 's comment above, we should apply the same to packages we install and use as part of TVM - at the bare minimum we should have tools to check packages haven't notified of major vulnerabilities and basic static analysis tools to catch easy to spot vulnerable code. As p

Re: [apache/tvm-rfcs] [RFC][Roadmap] microTVM roadmap (PR #53)

Merged #53 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/53#event-5934076030 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Add Managed Jenkins Infrastructure for TVM RFC (PR #49)

Merged #49 into main. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/49#event-5926474473 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm] [RFC][Tracking Issue] CMSIS-NN Integration (#8646)

All of this seems to have landed, huzzah! Thanks to @ashutosh-arm for coordinating this effort :smile_cat: -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/8646#issuecomment-1011984549 You are receiving this because you are subscribed to this thread. M

Re: [apache/tvm] [RFC][Tracking Issue] CMSIS-NN Integration (#8646)

Closed #8646. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/8646#event-5886330511 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm] [VOTE] Release Apache TVM v0.8.0.rc0 (Issue #9504)

+1 - Let's get this done and get ready for 0.9! :smile_cat: -- 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/9504#issuecomment-968902907

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Compilation Configuration Representation

[quote="junrushao1994, post:32, topic:11372"] On the other hand, my concern is the fragmentation of APIs. It has been a huge problem in the recent 1-2 years, and we do have alternatives not to do so. [/quote] Could you elaborate on this? I believe this isn't solely a UX issue but also a hygien

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Compilation Configuration Representation

[quote="tqchen, post:29, topic:11372"] This would results in two UX concepts. A target tag and config tag, and in the case of system implementations, possible two similar impls. [/quote] Which leads me to believe we should default to a `Config` level tag which is the highest level available?

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Compilation Configuration Representation

[quote="tqchen, post:27, topic:11372"] >From N0’s pov, the ability to directly pass in Target with a host field is a >good default solutions for this most comon combo, so in the case of API/UX >design, we might want to encourage this kind of usage without worrying about >additional fields for

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Compilation Configuration Representation

Hi @tqchen, Reading through the various needs there's nothing which hasn't already been covered by this RFC in combination with already accepted RFCs. Could you articulate the next steps? --- [Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-compilation-configuration-representation/

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Compilation Configuration Representation

Oh wow, I've been away for a few days and really appreciate the amount of discussion that's arrived :smile_cat: Thanks @mbs-octoml, @zxybazh, @tqchen, @comaniac, @junrushao1994 and @manupa-arm! Firstly let's address a few specifics which may help narrow the discussion slightly: [quote="junru

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Compilation Configuration Representation

Inspired by the work of @mbs-octoml, I give you a new RFC for CompilationConfig! # Summary [summary]: #summary This RFC supersedes [Migrating IRModules to Attributes](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0029-migrating-to-irmodule-attributes.md) by replacing the various attribute

Re: [apache/tvm] [Release] v0.8 Release Planning (#8976)

@junrushao1994 does this mean that 0.8 will go out with half finished implementations for things, such as library integrations (i.e. CMSIS-NN) and tvmc arguments (tvmc is not yet stable as there's breaking changes incoming)? If the process is just to take `main` and tag it, can we rapidly move t

Re: [apache/tvm-rfcs] Additional Target Hooks RFC (#10)

@areusch is there anything outstanding from you on this RFC? It seems ready to merge after the changes you've requested. -- 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/10#issuecommen

Re: [apache/tvm] [VOTE] Adopt round-robin assignment of reviewers for GitHub pull request reviewer assignment. (#9057)

-1 I don't believe this is will solve the problem of "assigning far too many pull requests to far too many people and not providing fair scheduling across all reviewers" and may introduce other issues. I believe this will result in is code owners missing pull requests which are relevant to them

Re: [apache/tvm-rfcs] Additional Target Hooks RFC (#10)

Thanks @mbs-octoml, I've incorporated this back into the document :smile_cat: -- 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/10#issuecomment-925653137

[apache/tvm-rfcs] Fix formatting in CMSIS NN RFC and remove plan (#35)

This fixes the formatting of the Markdown so that it properly renders code snippets, links and some of the lists. It also removes the upstreaming plan in favour of the GitHub issue. Co-authored-by: Ashutosh Parkhi You can view, comment on, or merge this pull request onli

Re: [apache/tvm-rfcs] Additional Target Hooks RFC (#10)

@mbs-octoml / @areusch apologies for the delay, there was a fair amount to tweak in here to reflect all the discussions around this RFC. Please could you take another look as I think this is lined up now :smile_cat: -- You are receiving this because you are subscribed to this thread. Reply to

Re: [apache/tvm] [VOTE] Adopt New Code Review Guideline (#8928)

+1 -- 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/8928#issuecomment-913698285

Re: [apache/tvm-rfcs] Additional Target Hooks RFC (#10)

Hi @mbs-octoml, sorry I missed a few replies! The reason I hoisted it outside of the `LowerTE` pass is that it effectively bypasses it anyway, `LowerExternalFunctions` in `te_compiler.cc` is a massive bypass which starts there and goes around most of TVM before it ends up as a `runtime::Module

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Additional Target Hooks

Just coming back to this thread, I believe there's a way to introduce the hooks in a less intrusive way to the `LowerTEPass`, by placing it just above it in `build_module.cc`. This should mean each Target can register a `relay_to_tir` `Pass` which is ran there rather than having to wire it via

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] C Device API

CC: @manupa-arm @grant-arm @areusch @stoa @MJKlaiber --- [Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-c-device-api/10874/2) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/em

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] C Device API

# Summary [summary]: #summary I want to write an RFC to provide an API which can be used by the C runtime to abstract the variety of driver APIs for different platforms. This is specifically catering towards RTOS abstractions for embedded device drivers. # Motivation [motivation]: #motivation

[Apache TVM Discuss] [Development/pre-RFC] Updated Docs pre-RFC

Just read through this and providing my own opinions. I'm a huge fan of L2 - Tour Style here, and I appreciate that it blends topics such as TVM and microTVM in the beginning rather than treating them as separate; it makes a lot of sense to me to use this to ensure we make all of TVM approacha

Re: [apache/tvm] [RFC] Tracking Issue for TECompiler (#7526)

@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

Re: [apache/tvm-rfcs] Additional Target Hooks RFC (#10)

Hi @jroesch, It'd be great to discuss this further, as there's some interesting points you've raised. > The lowering process should be a straight forward mapping from TE -> TIR, and > then any necessary customization should be possible in resulting passes which > are allowed to view the entire

[apache/tvm] [RFC][Tracking Issue] Additional Target Hooks (#8589)

1. [ ] Add hook for relay_to_tir - https://github.com/apache/tvm/pull/8423 1. [ ] Add hook for tir_to_runtime - 1. [ ] Migrate `relay.ext` to relay_to_runtime / constant_updater - 1. [ ] Migrate external codegen -> target conversion - -- You are receiving this because you are subscribed to this

Re: [apache/tvm-rfcs] Update the guideline of RFC tracking issues (#13)

> Meanwhile, I do agree that "nearly done" is too vague. I might rephrase it to > "when the RFC is about to be accepted, a committer should remind authors to > open a tracking issue and update the link before merging". How does that > sound? Thanks for updating this, I think this is much better

Re: [apache/tvm-rfcs] Update the guideline of RFC tracking issues (#13)

Hi @comaniac, Thanks for suggesting this, it's been on my mind :smile_cat: I'd suggest that "nearly done" is ambiguous? As a less ambiguous alternative I'd propose always opening a tracking issue (if the RFC is big enough to require it) when you raise an RFC and if it ultimately gets rejected

Re: [apache/tvm-rfcs] Additional Target Hooks RFC (#10)

CC: @tqchen @jroesch I think this overlaps with the TE Compiler work, would be good to get your feedback :smile_cat: -- 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/10#issuecomment-

[apache/tvm-rfcs] Additional Target Hooks RFC (#10)

This is the an initial RFC for adding additional hooks onto the `Target` to allow splitting up some of the compile flow but also unifying the registration of these additional functions. You can view, comment on, or merge this pull request online at: https://github.com/apache/tvm-rfcs/pull/10 --

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] [API Change] Formalizing c_backend_api

This is great @areusch! I appreciate the ability to re-introduce `c_backend_api.h` to leverage existing abstractions without having to necessarily use `c_packed_func.h`. It'd be great if we only required the single backend header file, I think the only thing that prevents is having to copy `f

[Apache TVM Discuss] [Development/RFC] [RFC] [uTVM] AOT optimisations for Embedded Targets

Glad to have your feedback @areusch :smiley_cat: [quote="areusch, post:11, topic:9849"] Adding `--no-typed-operators` makes sense to me, but would propose to change the name. `--no-typed-operators` reads pretty generically to me and could imply something like “operator + is aware of the types

[Apache TVM Discuss] [Development/RFC] [RFC] [uTVM] AOT optimisations for Embedded Targets

Hi @stoa, thanks for your observations and apologies for not replying sooner. I'm glad you agree with the initial direction taken and I appreciate that there may be a need to provide similar data to the user to that which is seen in DLTensor, at this stage we'll get that by providing the opti

[Apache TVM Discuss] [RFC] [uTVM] Embedded C Runtime Interface

# Summary This RFC outlines a set of additional APIs for the C Runtime to enable direct calling of an AOT micro entrypoint (https://discuss.tvm.apache.org/t/rfc-utvm-aot-optimisations-for-embedded-targets/9849) from a model descriptor which includes some model metadata, this is an alternativ

[Apache TVM Discuss] [RFC] [uTVM] Embedded C Runtime Interface

cc: @areusch @giuseros @stoa @manupa-arm @grant-arm --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-utvm-embedded-c-runtime-interface/9951/2) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.t