similar to: LLVM Fortran front-end

> Didn't you see Hal's reply? Hi Chris, Given that the email is *exactly* the same as yesterday’s I’d rather bet on a technical reason here. So probably no intention by Joshua ;-) Regards Jonas From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of C Bergström via llvm-dev Sent: Thursday, May 18, 2017 8:27 AM To: Joshua Cranmer <cranmer2 at

----- Original Message ----- > From: "Alex Bradbury" <asb at asbradbury.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>, "flang-dev" <flang-dev at googlegroups.com>, "Rob Neely" <neely4 at llnl.gov>, > "douglas miles (PGI)" <douglas.miles at

Hi Chad - We have a functional Fortran compiler, with the PGI front-end bridged directly to LLVM, all of our Fortran runtime libraries integrated, and the Clang driver adapted for use with the Fortran compiler. We're working with a few users at DOE who are trying to compile big applications with a binary version of the compiler. Work is ongoing to migrate the source code into an LLVM-style

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

Hi Chad, I can tell you that progress is being made on PGI's side; I'll let Doug/Rob provide more detailed updates. -Hal ----- Original Message ----- > From: "Chad Rosier" <mcrosier at codeaurora.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "flang-dev" <flang-dev at googlegroups.com>, "douglas miles (PGI)"

Hi Hal, I haven't been following this closely, but has there been any updates recently. Regards, Chad -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev Sent: Sunday, November 15, 2015 12:46 AM To: Hal Finkel <hfinkel at anl.gov> Cc: LLVM Dev <llvm-dev at lists.llvm.org>; flang-dev <flang-dev at

> On May 26, 2016, at 1:57 PM, Neely, Rob via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Chad, et al, > > In addition to Doug’s excellent technical update, I’ll note that we are > starting to have some discussions on the DOE side with PGI about > establishing a more formal review team made up of some key LLVM > stakeholders to help smooth the way for a broader

This process is certainly only open to a select group, so pragmatically it's closed. I can understand that it will certainly not be an easy process once it's public due to the amount of code and complexity. Maybe someone can comment on a specific issue - When we ported our Fortran front-end to target llvm, we found that Fortran ENTRY doesn't map very well to llvm ir. Can anyone who

Chad, et al, In addition to Doug’s excellent technical update, I’ll note that we are starting to have some discussions on the DOE side with PGI about establishing a more formal review team made up of some key LLVM stakeholders to help smooth the way for a broader public rollout of the Flang code base and eventual integration. We’ll probably rely on Hal and others here to help us figure out who

No closed doors intended here. Just a recognition that for something like an initial review to be useful, we probably have to be a bit careful in how many people we can reasonably involve before it could get unwieldy, and trying to be respectful of people’s time if we can nail down 90% of issues with a smaller group before going broader. I think we’d be fine with opening up the WebEx presentations

> On Nov 13, 2015, at 2:22 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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

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

On 7/16/2013 9:51 PM, Wan, Xiaofei wrote: > [Xiaofei] why? I don't understand it very well here, you mean it can > generate totally identical binaries as the original llc, including the > function order (function order may not affect code quality, but we > should make sure the output is same in each run)? Per <http://www-plan.cs.colorado.edu/diwan/asplos09.pdf>, function

-----Original Message----- From: Shuxin Yang [mailto:shuxin.llvm at gmail.com] Sent: Wednesday, July 17, 2013 1:50 AM To: Wan, Xiaofei Cc: Evan Cheng; Shuxin Yang; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: [LLVMdev] [LLVM Dev] [Discussion] Function-based parallel LLVM backend code generation On 7/16/13 7:23 AM, Wan, Xiaofei wrote: > Yes, the purpose is similar, we

On 10/23/2013 7:52 AM, lian li wrote: > According to our experiments with SPEC, we haven't observed > significant impact in terms of execution performance. In our > experiments, we run a list of 8 optimizations that require alias > analysis (including -licm, -gvn, -bb-vectorize,...), and for each > optimization we rerun our analysis so that its result can be used by >

*From:* flang-dev <flang-dev-bounces at lists.flang-compiler.org> *On Behalf Of *Eric Schweitz (PGI) *Sent:* Thursday, November 01, 2018 1:02 PM *To:* flang-dev at lists.flang-compiler.org *Subject:* [Flang-dev] RFC: Adding debug information to LLVM to support Fortran In order to support debugging in the Flang project, work has been done to extend LLVM debug information for the Fortran

On 11 June 2017 at 23:03, Craig Topper <craig.topper at gmail.com> wrote: > Try value->dump() assuming you're using a debug build. > > The information displayed is non-uniform. There are two different cases based on my sample program: (1) dump() shows the Type and *some* value which I don't understand what it is (2) dump() shows the instruction that

Dear Admin, It seems that mails from our iit.ac.in domain are being marked as spam. It would be nice if something could be done about this. Best Regards Ramakrishna On Tue, Mar 24, 2015 at 1:12 AM, Aditya Kamath < adityakamath+llvmdev at gmail.com> wrote: > Hi all, > > (I received many emails that my posts were marked spam, so I am re-sending > this from another email address

Hey guys, I'm learning that LLVM does not preserve faults during constant folding. I realize that this is an architecture dependent problem, but I'm not sure if it's safe to constant fold away a fault on x86-64. A little testcase: #include <stdio.h> int foo(int j, int d) { return j / d ; } int bar (int k, int d) { return foo(k + 1, d); } int main( void ) { int r =

Thanks, you have a lot of valid points there. I have myself long ago abandoned the path of using C as a backend language due to the very factors you mention. However, as I said, the document was put together in 30 minutes. Not exactly ready for prime time :-) I do agree that all of the things you mention should be described, including Lambdas, closures, and generators, but I must admit up