Re: [apache/tvm-rfcs] [RFC] Introducing DeclBuffer (PR #70)
We always need the original syntax to enable bidirectional property. It does not hurt though to enable sugars that allows us to have a combination on top. How about we start with the original syntax and then discuss sugar as a separate topic -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/70#issuecomment-1149818365 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/tvm-rfcs] [RFC] Introducing DeclBuffer (PR #70)
reuse T.alloc_buffer seems good，as long as there is no ambiguity for parser impl ：） -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/70#issuecomment-1149935097 You are receiving this because you are subscribed to this thread. Message ID:
[Apache TVM Discuss] [Announcement] [COMMUNITY] Tristan Konolige -> Committer
Please join us in welcoming @tkonolige as a new committer to TVM! Tristan has been consistently contributing to all parts of TVM, from the runtimes to the frontends, schedulers, tuning, documentation, CI and general bug fixing. Notably, he contributed libbacktrace and PAPI support. - [Commits History](https://github.com/apache/tvm/commits?author=tkonolige) - [Code Review](https://github.com/apache/tvm/pulls?utf8=%E2%9C%93&q=reviewed-by:tkonolige) - [Community Forum Summary](https://discuss.tvm.apache.org/u/tkonolige/summary) Congratulations @tkonolige ! --- [Visit Topic](https://discuss.tvm.apache.org/t/community-tristan-konolige-committer/12933/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/7823cb5d50948656d99fe3d6c04404066fa1fd794a25db8a07357870eb2e92c4).
[Apache TVM Discuss] [Announcement] [COMMUNITY] Tristan Konolige -> Committer
Well deserved! Congrats Tristan! --- [Visit Topic](https://discuss.tvm.apache.org/t/community-tristan-konolige-committer/12933/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/email/unsubscribe/e2659c370f67c1775fc54c47e76176617db7cb942d7e3cc18ed8498e1b9d6add).
Re: [apache/tvm-rfcs] [RFC] Introducing DeclBuffer (PR #70)
@areusch @Hzfengsy I've updated the RFC. It is ready for another look -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/70#issuecomment-1150342730 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/tvm-rfcs] [RFC] TUNIP: TVMScript Unified Printer (PR #74)
very sorry for the delay here. @junrushao1994 i guess i'm still a little fuzzy on the rationale for why we want to have two ways to parse TVMScript. I know this is a bit bigger than just this RFC, but with this RFC we're further pushing the cart down this path so I'd like us to be explicit about why. Relay has a single roundtrippable serialization format, as do most languages. I think we benefit from this in that we only have one set of tests to maintain. With TIR, my understanding is that we used Python as an AST parser since language constructs in TIR somewhat closely matched to Python. I'm not sure I see why we should want to have two different ways to do this--shouldn't we just have a single way to serialize TIR and parse it that always works? It seems like we could still expose this parser to various frontends via PackedFunc. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/74#issuecomment-1150642817 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/tvm-rfcs] [RFC] TUNIP: TVMScript Unified Printer (PR #74)
> Relay has a single roundtrippable serialization format, as do most languages. > I think we benefit from this in that we only have one set of tests to > maintain. To clarify, Relay has two roundtrippable serialization formats: text format and json. people use text format for readability, and in most usecases, go for json reliable serialization. > why we want to have two ways to parse TVMScript First of all, the RFC focuses on the printer, so would be great if we talk about the parser in the incoming RFC, but to clarify, we are not having two ways to parse TVMScript in the same language. Instead, for metaprogramming capability, one may need to interleave host language-based IRBuilder with the parser. > language constructs in TIR somewhat closely matched to Python. To clarify, TIR is a DSL independent of any existing language. It's somewhat close to HalideIR but has been evolving for years with lots of new features, for example, blocks. Python syntax is an add-on for usability but TIR design is in no ways matched to python. Anyways, I'm happy to talk more on the upcoming metaprogramming RFC. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/74#issuecomment-1150681679 You are receiving this because you are subscribed to this thread. Message ID:
