similar to: About OpenMP dialect in MLIR

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

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

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 [

Please find the reply inline below: On Tue, Feb 18, 2020 at 8:02 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Mon, Feb 17, 2020 at 10:29 AM Vinay Madhusudan <vinay at compilertree.com> > wrote: > >> Please find the reply inline below >> >> On Sun, Feb 16, 2020 at 12:59 AM Mehdi AMINI <joker.eph at gmail.com> wrote: >>

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

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

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

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

Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Chris Lattner < clattner at nondot.org>: > The central idea is to use a modifiable loop tree -- similar to > LoopInfo -- as the primary representation. LLVM-IR is converted to a > loop tree, then optimized and finally LLVM-IR is generated again for > subtrees that are considered profitable. This is not a new concept, it > has already

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

Am Sa., 16. Nov. 2019 um 10:56 Uhr schrieb John McCall via llvm-dev <llvm-dev at lists.llvm.org>: > Anyway, if we had that Clang-level library, t would be fairly > straightforward for someone interoperating with the C ABI to just > construct the appropriate Clang types and call those APIs. The main motivation is to have ABI-emitting code (in particular for OpenMP) shared between

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

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

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

Am Mi., 15. Jan. 2020 um 20:27 Uhr schrieb Chris Lattner < clattner at nondot.org>: > One you achieve consensus on data structure, there is the question of what >> IR to use within it. I would recommend starting with some combination of >> “existing LLVM IR operations + high level control flow representation”, >> e.g. parallel and affine loops. The key here is that

Hello, This is regarding recent/ongoing discussions about F18 being merged in LLVM. I was going through these threads, and I found few important points which were possibly left unanswered (or I might have missed few threads). URL: http://lists.llvm.org/pipermail/flang-dev/2019-December/000120.html Point: Is (3) AST -> FIR -> MLIR LLVM-IR -> LLVM-IR) in a shape where we can

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

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

Hi Eric, Renato Thanks again for the engagement and challenge on this, it is really useful feedback to know what we need to do to get F18 into the project in a way that everyone is happy with. I have tried to give timelines on the points addressed below where I can today. Clearly we need to do some work on points 8-11, but are the above plans/answers to points 1-7 sufficient at this stage and

> On Jun 2, 2020, at 4:21 PM, comex via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > While this is a different area of the codebase, another thing that > would benefit greatly from being moved out of Clang is function call > ABI handling. Currently, that handling is split awkwardly between > Clang and LLVM proper, forcing frontends that implement C FFI to > either