@Hzfengsy > There are similar sets of in-tree computational graph dialects that we > intended to refer to – both TOSA and Linalg for example are in the MLIR tree > and serve as computational graph dialects.
TOSA/Linalg are both graph dialects, but they don't fulfill the same function - TOSA is a higher-level representation than Linalg. As an example, IREE implements a lowering from TOSA to Linalg as part of its [TFLite support](https://iree-org.github.io/iree/blog/2021-07-19-tflite-tosa/#compiling-models). The closest example I can think of is [TCP](https://discourse.llvm.org/t/rfc-incubation-request-for-incubating-tcp-dialect-for-mlir/64883) vs. TOSA which was prompted by this lengthy [thread](https://discourse.llvm.org/t/rfc-proposal-for-a-high-level-ml-dialect-in-mlir/64249). However, that caused a huge amount of debate as to whether it was correct to have them both in the repo (similar to what we're seeing with Relax). The solution in the LLVM community is to have TCP first exist as an [LLVM incubated project](https://lists.llvm.org/pipermail/llvm-dev/2020-June/142548.html) outside of the mono-repo. To quote the [LLVM developer policy](https://llvm.org/docs/DeveloperPolicy.html#incubating-new-projects) on why they have such a process: > The burden to add a new project to the LLVM monorepo is intentionally very > high, but that can have a chilling effect on new and innovative projects. To > help foster these sorts of projects, LLVM supports an “incubator” process > that is much easier to get started with. It provides space for potentially > valuable, new top-level and sub-projects to reach a critical mass before they > have enough code to prove their utility and grow a community. This also > allows collaboration between teams that already have permissions to make > contributions to projects under the LLVM umbrella. This sounds extremely similar to the problem we're tackling with this RFC, just with an alternative solution. I think we need to be clear why we're arguing not for an incubation process (the MLIR/LLVM solution), but instead for this expedited approval process. It would also be good to include that argument in the RFC to make it clear that other processes have been considered. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1285672252 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1285672...@github.com>
