similar to: MLIR for clang

Hi Prashanth, On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Starting from May-June, we at "Compiler Tree" would start porting clang compiler to use MLIR as middle end target. If someone has already started a similar effort we would love to collaborate with them. If someone would like to work with us, we are ready to

Agreed! Is the code already available? What are your plans for it, and are you interested in collaboration with the rest of the LLVM community? -Chris > On Jan 11, 2020, at 11:58 AM, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, Prashanth, > > That's great news! It sounds like you've made a lot of progress, and I certainly hope that you

Hi Michael- 1. We intent to fork clang for MLIR at a particular release and develop. We will mostly merge with the master as soon as we reach a good milestones. Most of the development is expected to happen in github or some such version control system. 2. MLIR is extensible and we are hoping that constructs like exceptions can be represented in MLIR. As we dive deep into design we might be able

Hi Petr- 1. We compile SPEC benchmarks bwaves and xchange currently. We are close to compiling fotonik at this point. 2. We released the source as experimental for the community to take a look. Soon we will open source the entire history of development(we are working on the script to upload the history). thanks, -Prashanth On Mon, Feb 10, 2020 at 4:20 AM Petr Penzin via llvm-dev < llvm-dev

Neat, another fortran compiler option. Does anyone have a list/comparison of all the LLVM fortran compilers? I'm not really tracking this, since Fortran isn't really my area of expertise, but I've seen the following. Perhaps there are even more? "Flang". The original of the name, I think? Abandoned. https://github.com/llvm-flang/flang "Fort" -- fork of the above

Hi- In August we made an announcement of "FC: A new fortran front end" [1]. At that time to get an end-to-end solution, we made FC to emit LLVM IR directly. At present, we have upgraded FC to emit MLIR. Currently the language supported is close to Fortran-95. Apart from 400+ unit test cases, out framework passes two SPEC-2017 benchmarks successfully. Currently we are cleaning up the

Linearized array addresses are an issue in loop nest transformation. To alleviate the same, a multidimensional array indexing intrinsics have been proposed recently in the llvmp-dev mailing list [1]. From the mailing thread, it looks like there is a consensus on using intrinsics for communicating dimensions [2]. While working with our own loop transformation framework, we did a similar work on

Hi all, The TensorFlow team at Google has been leading the charge to build a new set of compiler infrastructure, known as the MLIR project <https://github.com/tensorflow/mlir>. The initial focus has been on machine learning infrastructure, high performance accelerators, heterogeneous compute, and HPC-style computations. That said, the implementation and design of this infrastructure is

On Jul 25, 2019, at 7:20 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Am Mi., 24. Juli 2019 um 16:13 Uhr schrieb Tim Northover > <t.p.northover at gmail.com>: … Siddharth’s original RFC <https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md> ... >> Apart from all that, I'm pretty disappointed to see this as an

On Mon, 9 Sep 2019 at 22:22, Chris Lattner <clattner at google.com> wrote: > Including a bunch of content, eg a full langref doc: > https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md Thanks Chris, that looks awesome! This one could perhaps be improved with time: https://github.com/tensorflow/mlir/blob/master/g3doc/ConversionToLLVMDialect.md Which I think was Hal's

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

Hi all, On Wed, 24 Jul 2019 at 16:14, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Mmmh, looks like Tim Northover is actively working on typeless/opaque > pointers, e.g. https://reviews.llvm.org/D64203 Yep, I'm spending as much time as I can on the project. I think there's not really much chance that it'll be required in this cycle (i.e. when we fork

Hi, I broke the MLIR build yesterday and the two Flang bots told me about it pretty much right away. Yay! That is how I always thought the setup should work (modulo that we all try not to break builds). Today I got emails from an MLIR bot and I was a bit confused. I looked at the configuration of the two MLIR bots and it seems they test commits one by one, with the backlog that you would

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.

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 [

Overall, I think it will be a good move. Maintenance wise, I'm expecting the existing community to move into LLVM (if not all in already), so I don't foresee any additional costs. Though, Hal's points are spot on... On Mon, 9 Sep 2019 at 18:47, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 3. As a specific example of the above, the current development

+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 >

Hi all Thanks for all the replies and engagement on this issue. First point, given the state of discussions today I would like to propose that we don't start the merge at 10:00 GMT on Monday 13th as proposed and we delay by at least 24 hours until after the scheduled F18 technical call on Monday afternoon. In order to help compile a plan of action, I've tried to compile a list of the

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