[llvm-dev] Adapting and open-sourcing PGI's Fortran frontend for LLVM

douglas miles (PGI) via llvm-dev llvm-dev at lists.llvm.org
Sat Nov 14 20:07:53 PST 2015


Here are answers to some of these questions, and a few others that haven't been asked (yet).

Doug


Will it support OpenMP?  Our plan-of-record includes full front-end support for OpenMP 4.x;  OpenMP for multicore CPUs built on top of the LLVM KMPC runtime should fall out pretty early;  it is too early to say when OpenMP 4.x accelerator features will be supported, but we already have outside parties who have volunteered to help with this.

Will it support OpenACC?  The hooks for OpenACC will be in the front-end, but we don’t have current plans to implement full OpenACC functionality in the LLVM infrastructure.  

Will it support CUDA Fortran?  We don’t have current plans to implement CUDA Fortran in the LLVM infrastructure.

What version of the Fortran standard is currently supported in the PGI Fortran compiler?  Full Fortran 2003, with some Fortran 2008 features.  We do not yet support Co-arrays, the block construct, or sub-modules;  these are high on our priority list with respect to implementation of the remainder of Fortran 2008.

What about vendor-specific extensions? The PGI Fortran compiler supports Cray pointers and a number of legacy extensions from DEC, IBM and other compilers.  All of these extensions will be retained in the open source version, but we are not making any attempt to proactively catalog and add other de facto standard extensions.

What processors will it support?  It’s important to remember this is a Fortran front-end and associated runtime libraries.  The front-end will emit LLVM IR which can be compiled by LLVM for a number of targets.  Most of the development work will likely occur on Linux/x86-64, but it will be straightforward to re-host and re-target the front-end to other targets.

What about support for ABIs beyond Linux/x86-64?  The bridge from PGI’s internal representation to LLVM IR is designed to support multiple ABIs;  support for certain additional ABIs will already be in place by the time the source code becomes available;  support for others should be straightforward to add.

Is the PGI Fortran front-end written in C++?   The PGI Fortran front-end is currently written in ANSI C;  we are re-engineering it to conform to LLVM coding guidelines, and will do a significant amount of refactoring and re-writing along the way;  it is still TBD whether any parts of the front-end will be re-written or augmented using C++.

Will the modules format be compatible with the PGI Fortran compiler? Array descriptors?  Name mangling?  Fortran input/output files?  Yes, but we may change the format of some of these from that used in the current PGI Fortran compiler.

Is any of the source code of the PGI Fortran compiler actually written in Fortran? Some of the Fortran intrinsic math library routines and intrinsic modules are written in Fortran, and we have no current plans to change that.

Will there be binary versions of the compiler available before the source code release?  If so, will I be able to dump the LLVM IR prior to invocation of the LLVM back-end?  Yes and yes, but we don’t yet have a timeline.  Stay tuned.

What about the existing Flang project?   We have already had discussions with most of the contributors to the existing Flang project.  We hope and expect to join forces in a unified effort.

Will you still offer NVIDA/PGI-branded compiler products?  Yes.  Eventually, the Fortran compiler in the software products we ship and support will use the open source front-end and runtime, augmented with value-add features for our customers.  There will be a transition period through the initial development during which the two front-end and runtime source code bases will be distinct.

How can I help?   We are working on a list of tasks that contributors can potentially work on prior to the open source phase of the project.  Stay tuned.




-----Original Message-----
From: C Bergström [mailto:cbergstrom at pathscale.com] 
Sent: Saturday, November 14, 2015 2:22 AM
To: Alex Bradbury
Cc: Hal Finkel; LLVM Dev; flang-dev; douglas miles (PGI); Rob Neely
Subject: Re: [llvm-dev] Adapting and open-sourcing PGI's Fortran frontend for LLVM

On Sat, Nov 14, 2015 at 2:41 PM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> What will happen to flang development efforts?

I hope Hal is correct, but more likely he's just giving a tactful and politically correct answer.

Reality is more likely that flang will have better code and design.
We'll end up with a Fortran front-end that mirrors the current quality and capability as PGI. Frankly and no offence meant, but I would have been much happily if they had just sponsored development on flang and or worked with NAG (who has a much stronger reputation for actual Fortran conformance - I've never tested PGI tbh)

Keep in mind that PGI's Fortran fe is likely c and has been around for a while.. (Since the 90's?) The PGI engineers are welcomed to placate my curiosity and correct any wrong assumptions. I hope like heck that we don't end up with actual Fortran code (in the FE or runtime). That would introduce a circular build dependency which I can assure you is a major pita.

Other curiosities - will the module format be compatible with PGI compiler? What about F2K8 and future standards? Arrays? Will they
(when?) publicly document how they are mapping things in Fortran to llvm ir or we'll just end up with a code drop? (I personally know of a few challenges with mapping Fortran to llvm ir)

Will we have to do a public information request or how much is PGI being paid for this..

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------


More information about the llvm-dev mailing list