[flang-dev] Notes from the Flang Roundtable
Richard Barton via flang-dev
flang-dev at lists.llvm.org
Mon Nov 22 01:36:54 PST 2021
> If the decision is to focus on Fortran 2003 next, will patches for more recent standards be accepted?
I think we should definitely accept contributions for newer language standards. Doing so would allow interested parties to implement what they need, without having to wait for the rest of the earlier standards that they don’t need. That would make Flang more useful to more users earlier.
Same argument for performance – we should be accepting any patch that results in more clean/optimal FIR or LLVM IR output.
From: flang-dev <flang-dev-bounces at lists.llvm.org> On Behalf Of Damian Rouson via flang-dev
Sent: 18 November 2021 22:32
To: Perry-Holby, Alexis <aperry at lanl.gov>
Cc: Andrzej Warzynski via flang-dev <flang-dev at lists.llvm.org>
Subject: 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:
* 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the flang-dev