[flang-dev] [EXTERNAL] Re: Notes from the Flang Roundtable

[Perry-Holby, Alexis via flang-dev]

Regarding the support for various Fortran standards and whether to optimize features from older standards…  I appreciate that there are modern codebases out there that may rely solely on the newest version of the standard, but there are still a LOT of important codes that have not gone past F2003, if that, and we need to support those use cases as well.  These codebases may not have the ability (read financial, logistical, etc.) to be rewritten in the newest version of Fortran, so we as compiler developers need to help them make their codes as fast as possible by providing a high-quality optimizing compiler even on the old standards.

-- Alexis


From: Damian Rouson <rouson at lbl.gov>
Date: Thursday, November 18, 2021 at 3:32 PM
To: "Perry-Holby, Alexis" <aperry at lanl.gov>
Cc: Andrzej Warzynski via flang-dev <flang-dev at lists.llvm.org>
Subject: [EXTERNAL] Re: [flang-dev] Notes from the Flang Roundtable

I had to leave the call early so I don't know whether the topics below were addressed.  Hopefully my comments below are useful.

On Thu, Nov 18, 2021 at 12:37 PM Perry-Holby, Alexis via flang-dev <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>> wrote:

OTHER TOPICS

  *   Driver can make an executable now!

     *   Is now a good time to switch name from flang-new to flang?
This it sounds like a good idea to me.  On a possibly related note, at what point in the process does an end user have the experience of installing flang and producing an executable file with something like "flang hello_world.f90"?  And when will the end user be able to install flang via common package managers?


  *   Two different ways to approach continued development: keep chasing standards or make a high-quality F95 compiler with optimizations and such?
The utility of a compiler only becomes non-zero once the compiler supports the standards a code uses.  Every project I lead uses Fortran 2018.  Also, any support for Fortran 2018 parallel features might improve  performance more than optimizing Fortran 95 serial features.  For example, any time spent on optimizing the Fortran 95 FOR ALL statement would be better spent offloading DO CONCURRENT to GPUs -- especially given that the Fortran 2018 standard officially declares FOR ALL to be obsolescent. Fortran 2018 also deletes some features so you probably don't want to optimize any of those.

Progressing through the standards chronologically also means missing some attractive low-hanging fruit.  For example, supporting the Fortran 2018 collective subroutines is much easier than supporting Fortran 2008 coarrays. I've worked on several production applications for which the collective subroutines provide all of the parallel communication needs even with no coarrays anywhere in the codes.

If the decision is to focus on Fortran 2003 next, will patches for more recent standards be accepted?

Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20211119/6b518743/attachment.html>