similar to: Proposal for CIRCT incubator project

Sure, I'll summarize with respect to the criterion in the document: - Must be generally aligned with the mission of the LLVM project to advance compilers, languages, tools, runtimes, etc. CIRCT is a compiler which is built around LLVM/MLIR. We anticipate building code generation for ASIC and FPGA backends along with specialized accelerators, while leveraging existing LLVM backends for

> On Jul 8, 2020, at 8:52 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It would be nice to have an external MLIR user in the project, and > this project seems really well organised and relevant. +1 from me, > too. I think that flang beat us to the punch as the first external MLIR user :-) but thank you for your support Renato! -Chris > > On

Renato, I'm happy to kibitz on the build problems. Cmake seems to be working well at this point for us, but it took quite a bit to get there and there are some pitfalls. I'm aware of some namespace issues in mlir, but haven't gotten around to dealing with them. Steve On Thu, Jul 9, 2020, 3:47 AM Renato Golin <rengolin at gmail.com> wrote: > On Wed, 8 Jul 2020 at 22:43,

Hi Steve, Thanks for the update! This will fix the ugliest hack I have on my build script. I know I wasn't doing the nicest thing, but it's nice to see that what I needed wasn't that far away. I'll update my scripts and get back to you. Really appreciate, thanks! Renato On Fri, 10 Jul 2020, 07:59 Stephen Neuendorffer, < stephen.neuendorffer at gmail.com> wrote: >

Uh-oh: Failed to publish: GitHub error 404 on POST https://api.github.com/repos/llvm/mlir-npcomp/pulls/42/reviews: Not Found (The llvm organization may need to authorize Reviewable as an accepted third party application.) Can an admin take the suggested action on the mlir-npcomp project in the LLVM org? I've followed the instructions in this help doc

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

Has anyone tried out reviewable.io yet? It integrates with GitHub pull requests, but provides a separate UI for doing the review which promises to fix a lot of the issues encountered with Github's review interface. Some of the things it claims to support which seem like important additions: - Tracking the resolved status of each discussion point - Rebasing a PR without losing review history.

On Fri, Sep 11, 2020 at 6:53 PM David Blaikie <dblaikie at gmail.com> wrote: > Is there any observable difference between "Squash and Merge" or "Rebase > and Merge" when "enforce linear history" is enabled, then? > "Squash and Merge" will only generate one commit. > > On Fri, Sep 11, 2020 at 3:45 PM Stephen Neuendorffer via llvm-dev

On Wed, Jun 24, 2020 at 9:54 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > On Tue, Jun 23, 2020 at 2:40 PM Stella Laurenzo via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > We originally started it as a fork of the LLVM repository, but > transitioned to the MLIR standalone template, and we found it more > productive to iterate out of tree in this fashion,

The LLVM incubator projects have been using github PRs for reviews and so far haven't really seen any significant issues. The biggest confusion so far has not been with reviews but with the difference between "rebase and merge" and "squash and mere". We have used basically 3 different processes: Method 1: start a review with one commit on a new branch (typically in a

These errors seem pretty pervasive for me on a clean build. It appears that it arises because when tablegen'd headers are included in a .h file, every place where that .h file is used needs a dependency on the corresponding IncGen targets. This seems broken in the short term and unmaintainable in the long term. There really needs to be a way of automatically generating the right

Hi all, Today, we maintain a high bar for getting a new subproject into LLVM: first a subproject has to be built far enough along to “prove its worth” to be part of the LLVM monorepo (e.g. demonstrate community, etc). Once conceptually approved, it needs to follow all of the policies and practices expected by an LLVM subproject. This is problematic for a couple reasons: it implicitly means that

Reply to Kiran Chandramohan: > You are welcome to participate, provide feedback and criticism to change the design as well as to contribute to the implementation. Thank you Kiran. > But the latest is what is there in the RFC in discourse. I have used this as reference for the response. > We did a study of a few constructs and clauses which was shared as mails to flang-dev and the

Hi, I have few questions / concerns regarding the design of OpenMP dialect in MLIR that is currently being implemented, mainly for the f18 compiler. Below, I summarize the current state of various efforts in clang / f18 / MLIR / LLVM regarding this. Feel free to add to the list in case I have missed something. 1. [May 2019] An OpenMPIRBuilder in LLVM was proposed for flang and clang frontends.

Please find the reply inline below On Sun, Feb 16, 2020 at 12:59 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Sat, Feb 15, 2020 at 10:42 AM Vinay Madhusudan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Reply to Kiran Chandramohan: >> >> > You are welcome to participate, provide feedback and criticism to >> change the

On Wed, Sep 11, 2019 at 1:54 PM David Greene <greened at obbligato.org> wrote: > Mehdi AMINI <joker.eph at gmail.com> writes: > > > Of course by its nature, MLIR doesn't lend itself to concrete semantic > >> descriptions, though I would expect the affine dialect (and others) to > >> have documentation on par with the LLVM IR. > > > > >

Thanks for the reply! It sounds like LLVM IR is being considered for optimizations in OpenMP constructs. There seems to be plans regarding improvement of LLVM IR Framework for providing things required for OpenMP / flang(?) Are there any design considerations which contain pros and cons about using the MLIR vs LLVM IR for various OpenMP related optimizations/ transformations? The latest RFC [

On Tue, Sep 10, 2019 at 1:40 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > But perhaps more importantly, as Hal states clearly, is the need for > > an official specification, similar to the one for LLVM IR, as well as > > a formal document with the expected semantics into

Hi Galina, How can I set a builder to "batch mode"? I could not find any documentation or examples for that... Best, Christian On Mon, Aug 3, 2020 at 9:33 AM Christian Kühnel <kuhnel at google.com> wrote: > Hi folks, > > happy to set it to batch mode, if someone tells me where to configure it :) > > Otherwise we could also upgrade the machine from 16 to 32

+1 for batching. In practice it's probably more important that things get run for every MLIR checkin, and not necessarily for every LLVM checkin. Steve On Fri, Jul 31, 2020 at 9:26 AM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Indeed there is quite a backlog here right now: > http://lab.llvm.org:8011/builders/mlir-windows and here >