<div dir="auto">Thanks, Mehdi for bringing this back up. I am indeed still interested in seeing if we can incubate this project. Especially now that we have the topic of MLIR python bindings upstream open with commits flowing, this gives us an outlet to (eventually) factor out the bindings I built in npcomp and have a non trivial consumer of them in the ecosystem.<div dir="auto"><br></div><div dir="auto">This project is earlier phase than the other proposal (circt) and essentially has so far been two of us doing virtual pair programming via a discord channel and f2f meetings to get it bootstrapped (more slowly than we would have liked, amid our regular jobs).</div><div dir="auto"><br></div><div dir="auto">Just yesterday we hit the milestone where:</div><div dir="auto">  - we can import python function ASTs to our basicpy and numpy dialects (currently some simple scalar code, control flow and numpy ufunc calls like np.add)</div><div dir="auto">  - minimal frontend pipeline to lower to our "TCF" dialect, intended to represent dynamic language originating tensor programs</div><div dir="auto">  - pluggable backend pipeline that compiles to an in-tree reference JIT runtime and to IREE</div><div dir="auto">  - enough plumbing to be able to use a decorator to compile a python function and produce a stub that will run it on one of the backends in place of the python func.</div><div dir="auto"><br></div><div dir="auto">With the e2e spike in place, we'd like to collect and start disseminating our learnings as we continue. Specifically, there are a number of things that may help us think about evolving the MLIR frontend story, and having built a reference runtime, I think we've developed some opinions about what really should be in MLIR core on that axis (versus re-invented by every full featured backend like our npcomprt, IREE, and things like TFRT). Having the bare minimum in those areas may help us reason about those topics in a way that is hard to do with the more fully built projects.</div><div dir="auto"><br></div><div dir="auto">In any case, I'd love to move this project into the incubator and continue to work on it there in closer proximity to the community. That may also help us with collaborations that are structurally harder to initiate with the current project placement.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 9, 2020, 12:58 AM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 24, 2020 at 2:37 AM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">On Jun 22, 2020, at 11:07 PM, Stella Laurenzo via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br><div><blockquote type="cite">Per the recent (seeming) consensus regarding incubating new projects under the LLVM organization, I would like to trial the process by requesting to incubate <a href="https://github.com/google/mlir-npcomp" target="_blank" rel="noreferrer">mlir-npcomp</a>. The project is still quite young and has been primarily developed part time by myself and Sean Silva over the last ~2 months. We set it up following discussion of a <a href="https://llvm.discourse.group/t/numpy-scipy-op-set/768" target="_blank" rel="noreferrer">Numpy/Scipy op set</a> and also in conjunction with a proving ground for high level dialects/transforms for lowering from "numpy-aligned" frontends (e.g. sometimes labeled TCF/TCP).<br></blockquote><div><br></div>Awesome.</div><div><br><blockquote type="cite"><div dir="ltr"><div>So, as the first one walking through the door, what is the process we would like to follow? I'm happy to provide more information/discussion, but I'd also be happy if with just an LGTM and someone creating an "mlir-npcomp" repository under the LLVM GitHub organization and working the rest out as we go.</div></div></blockquote><br></div><div>I feel like we have general consensus that something like an incubator process is a good idea, but I think we should converge on adding a new section to the LLVM Developer Policy that describe what an incubator project is, and outline the requirements (following the policy etc).</div><div><br></div><div>Could you help put together a draft of a patch?  If not, I can take a look at this this weekend.</div></div></blockquote><div><br></div><div>Now that the proposal landed, we could resume the discussion on this proposal?</div><div><br></div><div>I haven't been involved with mlir-npcomp directly so far, but I'm very interested in seeing this moving forward: it has a lot of potential as an incubator project!</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div>
</blockquote></div>