similar to: [RFC] Create llvm/lib/Frontend

On Thu, Nov 14, 2019 at 9:59 AM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think the idea of more expanded frontend support library makes sense. > The main use case that I've heard for such a library is to help frontends > generate LLVM IR that interfaces with the local native C ABI. > I agree it would be good to have a library for shared frontend

On 11/18, Chris Lattner wrote: > > > > On Nov 12, 2019, at 9:19 PM, Doerfert, Johannes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > I was hoping to introduce a new top level library in llvm/lib/Frontend > > for code that is (mainly) used by LLVM frontends but not by one > > exclusively. At first, I would place the OpenMP-IR-Builder [1] (and

This seems to be happening to me, too. I think this happens for me on "ninja check-llvm" in a clean build. Let me know if you need more info. On Tue, Dec 10, 2019 at 2:22 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Jay, > > I am not sure why this happens. > Can you give me some information so I can reproduce it: > Is this happens

Jay, Hiroshi, did [0] resolve the problem you've seen. [0] https://github.com/llvm/llvm-project/commit/d23c61490c282a7a8f29aaa5c021cbfdaf87fb6f On 12/10, Doerfert, Johannes wrote: > I think the problem is that only clang has a dependence on the new > library and when you check LLVM without building clang it does not exist > yet. I will commit a LLVM patch today that will cause LLVM

Johannes, This patch seems to be causing test failures when I just do "ninja check", without running "ninja" or "ninja all" first. $ CC=clang CXX=clang++ cmake -G Ninja ~/git/llvm-project/llvm -DLLVM_USE_LINKER=lld -DLLVM_PARALLEL_LINK_JOBS=4 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 && ninja check [...] FAIL: LLVM ::

Hi, [I started this discussion on a single mailing list (flang-dev [0]) but this is a notice to the others (llvm, clang, openmp) so we hopefully get all interested parties involved.] This is an RFC for the design of the OpenMP front-ends under the LLVM umbrella. It is necessary to talk about this now as Flang (aka. F18) is maturing at a very promising rate and about to become a sub-project

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 01/15, Nicolai Hähnle via cfe-dev wrote: > On Tue, Jan 14, 2020 at 11:41 AM Renato Golin <rengolin at gmail.com> wrote: > > We rarely approve some patches and not others in a series, and when we > > do, we ask people to create a new series without the approved patch, > > or split them, so that we can continue reviewing the series. > > This has simply not been

We are working on OpenMP target offloading for GPUs in Flang, and adopting the same code generation strategy. The proposal is affecting us. It would be nice to know more details about the proposal. So we can prepare ourselves to adapt flang (if everything goes on the way). Have you find and a solution for data sharing? How are you going to manage data sharing for SPMD and non-SPMD? From: cfe-dev

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.

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 6/11/20 4:04 PM, James Y Knight wrote: > I think the expectation is that LLVM remains at the bottom of the > dependency tree, with frontend-support depending on LLVM, and Clang and > Flang depending on frontend-support (and LLVM). > > Not everything which makes sense to share between clang and flang makes > sense to be part of llvm core. E.g., implementation of a

On 6/11/20 3:32 AM, Andrzej Warzynski wrote: > > > On 11/06/2020 00:49, Michael Kruse wrote: >> Am Mi., 10. Juni 2020 um 10:04 Uhr schrieb Doerfert, Johannes via >> flang-dev <flang-dev at lists.llvm.org>: >>> I'm not against a subproject *but* if we also move the existing >>> llvm/lib/Frontend stuff, that would introduce a dependence from

For those of us not familiar with clang internals, it would be helpful if you could describe the parts of clang that you're considering sharing and explain what existing code they would replace in flang (if any) and what benefits we gain by sharing them. In particular, these were mentioned previously: DiagnosticsEngine, SourceManager, SourceLocation, FileManager, VFS Thanks, Tim On

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

Am Mi., 10. Juni 2020 um 10:04 Uhr schrieb Doerfert, Johannes via flang-dev <flang-dev at lists.llvm.org>: > I'm not against a subproject *but* if we also move the existing > llvm/lib/Frontend stuff, that would introduce a dependence from > llvm-core to this project, which I think is uncommon. We could also have > both. At the end of the day it depends on the benefit we would

This is an RFC to add analyses and transformation passes into LLVM to optimize programs based on an abstract notion of a parallel region. == this is _not_ a proposal to add a new encoding of parallelism == We currently perform poorly when it comes to optimizations for parallel codes. In fact, parallelizing your loops might actually prevent various optimizations that would have been applied

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

We would still know that. We can do exactly the same reasoning as we do now. I think the important question is, how different is the code generated for either mode and can we hide (most of) the differences in the runtime. If I understand you correctly, you say the data sharing code looks very different and the differences cannot be hidden, correct? It would be helpful for me to understand your

Hi everyone, I have some very good news for everyone interested a production-quality Fortran frontend for LLVM: The U.S. Department of Energy’s National Nuclear Security Administration and its three national labs have reached an agreement with NVIDIA's PGI division to adapt and open-source PGI's Fortran frontend, and associated Fortran runtime library, for contribution to the LLVM