mbaret commented on PR #95:
URL: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1285672252

   @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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tvm.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to