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. 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). Just yesterday we hit the milestone where: - 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) - minimal frontend pipeline to lower to our "TCF" dialect, intended to represent dynamic language originating tensor programs - pluggable backend pipeline that compiles to an in-tree reference JIT runtime and to IREE - 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. 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. 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. On Thu, Jul 9, 2020, 12:58 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Wed, Jun 24, 2020 at 2:37 AM Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Jun 22, 2020, at 11:07 PM, Stella Laurenzo via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> Per the recent (seeming) consensus regarding incubating new projects >> under the LLVM organization, I would like to trial the process by >> requesting to incubate mlir-npcomp >> <https://github.com/google/mlir-npcomp>. 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 Numpy/Scipy >> op set <https://llvm.discourse.group/t/numpy-scipy-op-set/768> 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). >> >> >> Awesome. >> >> 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. >> >> >> 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). >> >> Could you help put together a draft of a patch? If not, I can take a >> look at this this weekend. >> > > Now that the proposal landed, we could resume the discussion on this > proposal? > > 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! > > -- > Mehdi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200711/84cea345/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4