NVIDIA’s involvement in fir-dev, the fir-dev branch on github flang-compiler/18-llvm-project, is coming to a close.
Thank you to everyone who contributed to fir-dev and to all of the dedicated contributors and reviewers who helped upstream code to llvm-project.
As of April 21, 2022, NVIDIA will transition to contributing directly to llvm-project. NVIDIA will no longer be contributing to or upstreaming code from fir-dev.
Access to fir-dev will remain open. There will be no change in the access policies or permissions without consensus of the flang community. Others are free to continue to use fir-dev.
NVIDIA will continue to contribute to llvm-project/flang with the same dedication that we have in the past. Our commitment to flang is unwavering.
– Steve
FAQ:
Q: What about the NVIDIA patches in fir-dev that are not yet upstreamed?
A: NVIDIA will work with the community to land these patches directly into llvm-project. NVIDIA will not be updating fir-dev as this happens.
Q: Will NVIDIA review, approve, or merge changes into fir-dev after April 21?
A: No. We are redirecting our efforts to llvm-project. NVIDIA will still be participating as always, but directly in phabricator and llvm-project.
This is great news. Many thanks to Nvidia and the FIR team (@schweitz@jeanPerier valdonaldson). Special thanks to @clementval@psteinfeld and the community for the upstreaming effort!
As mentioned in Today’s call, we are done with upstreaming. We still see couple of tests that are behaving differently (~ 100). These failures are likely due to change in LLVM/MLIR between fir-dev and upstream (fir-dev has not been rebased in a long time). So we now switch to look for this issue upstream and will contribute patches when needed.
(the call notes haven’t mentioned an update for classic flang since over a year though there’s definitely still activity, so would be interested in anything you can say about a status there as well…)
Classic Flang call notes are available here. We continue to have bug fixes, support for newer versions of LLVM, improvements in debug support (arrays, modules), quad precision, windows, mac support etc.
We are currently using a somewhat hacky fork of classic-flang as a possible fortran compiler in conda-forge (for various reason it has not yet been able to replace using gfortran on windows through mingw, for example to compile scipy, netlib-lapack or compile openblas with openmp support).
I did not want to ask for the needs of conda-forge to be prioritized, more to get an insight in the status, as it had been stated (authoritativeness is unclear to me though; the person has only a handful of classic flang commits) that:
Classic flang will be killed immediately after a windows version of f18 (new flang) is available. Further, there won’t be a classic flang with an LLVM version that’s the same as the f18 (new flang) version, and furthermore, both drivers will have the same arguments.
But now that you are explicitly asking for features I’d like to see the most, what I’d like to be able to do is compile lapack / openblas / scipy (in that order of priority, list continues of course) with LLVM flang (don’t mind if it needs experimental flags, patches, or performance is bad, etc.) on windows. That’s not saying that we’d switch our production compilers immediately, but at least we could test the packaging (and provide compiler bug reports, if any), or push the flang-packaged artefacts into a dev channel in order to allow (e.g. performance) testing them.
As a sidenote, I’ve been waiting for a capable & freely available fortran compiler on windows for a while (followed flang before LLVM upstreaming was even on the table publicly, so I have some attachment to it by sheer length of lurking), but ultimately it’s going to be whatever works. Thus I feel I should note that LFortran is explicitly pushing towards satisfying those very same needs (see also here). Not that we won’t build flang anyway once it arrives, just that - once in place - switching toolchains needs to meet a higher benefit threshold to justify the cost of the work involved.
Thanks for the feedback and details. I think that comment is more-or-less right, I doubt any user of classic flang will stick to it if LLVM flang can do a better (or even similar) job for their usecase. Compilers have a large set of features though, so my guess is that the two flangs will live alongside eachother for some time - we’re all working to make that window as short as possible.
BLAS/LAPACK is certainly on our list of workloads, but SciPy not - @kiranchandramohan is maintaining that list. If you are able to give LLVM Flang a try on one of those workloads then sharing your experience on those tickets, including raising bug reports will give you a better chance of getting flang there sooner.
I’ll try once LLVM 15 rolls around. For various infrastructural reasons I need to package flang first in order to test-drive it on other packages. That’s also why I was interested in having the experimental flag to enable compilation as soon as possible.
