The review of “Rename flang-new to flang” begins now and runs through
April 5th, 2023. The proposal is available online.
Feedback is an important part of the LLVM Proposal process. All review
feedback should be either on this thread or, if you would like to
keep your feedback private, directly to one of the review managers.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of LLVM. When writing your response, here are some questions you might want to answer in your review:
What is your evaluation of the proposal? What positive or negative
implications would accepting this have?
Do you have experience from other communities that relates to this
issue and is important to consider?
How involved have you been in the LLVM project? Frequent contributor,
occasional contributor, user of LLVM libraries, user of LLVM-based tools,
or other?
Self Evaluation: How much effort did you put into your review and how
knowledgeable are you about this area? For example, a quick reading or an
in-depth study?
In addition to your opinion and thoughts, please include any additional
framing that may be useful.
“Flang (also known as “Classic Flang”) is an out-of-tree Fortran compiler targeting LLVM. It is an open-sourced version of pgfortran, a commercial Fortran compiler from PGI/NVIDIA. It is different from the new Flang (formerly known as “F18”),”
this project team may want to consider an entirely new name as part of this renaming review.
Say Ffrend for Fortran front-end to be pronounced /frend/ may come across as more friendly to the LLVM Fortran Community!
Possible alternatives: flung, fling, flong or mimicking GNU, which stands for “GNU’s Not Unix,” we could go with something like fnf, which expands to “Flang’s Not Flang”. In moments of frustration, we would have the option to expand fnf to “f’n flang”.
To those of you suggesting other names, I appreciate the outside the box thinking, but this is not on the table. The name of the compiler will be flang, and this proposal does not seek to change that. The issue is that, at present, the name of the executable is flang-new. This proposal seeks to give it its proper name.
If you would, please make sure to read the proposal before commenting, and follow the guidance given in the initial post.
What is your evaluation of the proposal? What positive or negative
implications would accepting this have?
Do it immediately. flang-new resembles an amateur form version control and not consistent with a serious software project like LLVM. There should be one driver (like clang) and a compiler flag to change its behavior.
I withdraw my support for this proposal, because it has been proven to confuse users into believing that flang-new has reached production readiness. I had expected that the type of people who would be engaged with LLVM Fortran at the level required to install it from the source tree would know better. I was wrong.
Do you have experience from other communities that relates to this
issue and is important to consider?
I’ve been an NWChem developer for 17 years and have supported a large number of compilers over the years in our bespoke build system. One thing is absolutely true: reasoning about the behavior of a compiler based on its name is foolish and error-prone. Compiler behavior must be inferred from the results of $(FC) -v or similar.
I confess that in the past, I argued against changing the name because of NWChem, but that’s because I am lazy and didn’t want some NWChem developer to have add the 5-10 lines of GNU Make code required to detect the behavior of LLVM Fortran front-ends properly. However, developer laziness is not a serious technical argument and I am disappointed in myself for ever have done this.
How involved have you been in the LLVM project? Frequent contributor,
occasional contributor, user of LLVM libraries, user of LLVM-based tools,
or other?
I’ve been tangentially involved in the LLVM Fortran project since I was brainstorming ideas with Hal Finkel in an Argonne conference room more than a decade ago. I have used and supported PGI-based flang compilers in NWChem and other open-source projects. I am an infrequent user of “new” flang. For all of my usage, I am only interested in using the “pure” version, and not the version that uses gfortran etc. for code generation.
Self Evaluation: How much effort did you put into your review and how
knowledgeable are you about this area? For example, a quick reading or an
in-depth study?
I read this entire thread and the proposal, albeit with less attention to detail than I put into my most recent employment contract. I put about 10 minutes into writing this review. I have been thinking about this exact topic for years, so it was not particularly strenuous on my brain to comment.
I read this proposal, then spent an entire day discussing it with a number of people privately, after which point I was very much uncertain about what the right thing to do was, despite having originally been quite confident. What caused me to reverse my stance was seeing an actual user response to seeing this proposal, which validated Steve’s concerns exactly.
I am slightly in favour for the renaming sooner than later. However, the website is not up to it. It’s content is mainly focussed on developers. It does not state what flang supports and where is still work needed.
Trick question. Show me where on the website I can find out what the OpenACC level of support is?
The flang code owner (me), the top contributor (@klausler), and the most active contributors to flang support this proposal. However, we all believe it is premature to make the change now & request to wait until flang is more fully featured.
We support removing flang-to-external-fc.
When the HLFIR work is landed, we support updating flang-new to generate executables without any special arguments.
What positive or negative implications would accepting this have?
We believe users will be misled and disappointed due to missing language features if we rename the driver to be flang now. We are keenly aware that first impressions are important and therefore want to wait to provide an excellent introduction for flang users. Early adopters and interested users can use flang-new today. It’s not a burden for them. Downstream developers can easily rename the driver to be flang if they choose.
Do you have experience from other communities that relates to this issue and is important to consider?
Yes, I have been involved in several projects to replace existing technologies with new technologies. Using flang-new is an excellent way to approach the introduction of LLVM flang to the Fortran community because it is easily and explicitly opt-in.
How involved have you been in the LLVM project? Frequent contributor, occasional contributor, user of LLVM libraries, user of LLVM-based tools, or other?
I am code owner of flang and a member of the team that has contributed most of llvm-project/flang. I attend most flang weekly calls, give status updates as lightning talks at LLVM dev conferences, post status in various forums, active in the flang slack channel, triage issues that are reported on github, participate in phabricator reviews, post and reply on discourse, etc.
Self Evaluation: How much effort did you put into your review and how knowledgeable are you about this area? For example, a quick reading or an in-depth study?
In-depth study. I am very involved. On the topic of flang readiness, I am the person who maintains and posts the list of unimplemented TODOs for flang. It is a list that I track on a daily basis. I am also a member of the team that builds NVIDIA nvfortran and before that PGI pgfortran, so I have a lot of experience working with programmers who use Fortran.
Are there precedent on this: either in LLVM or in other projects where a different name for the binary/entry point would be used during development until “feature completeness”?
For example, I believe at least clang was named as-is from day 1 even though it was far from complete.
It would be good to know if we’re “innovating” on the approach here or doing something fairly common, and if we’re innovating maybe trying to explain what makes it different from every other OSS project ever.
I think we should implement this proposal and rename flang-new to flang. I think it’s important that users are encouraged to use projects that we have deemed good enough to include in the top-level of the monorepo, and I think renaming the binary will do that.
I understand the argument against the rename and how this may impact users’ perception of the tool, but if we are actively trying to discourage users from using flang, then I would question why it’s even in the monorepo in the first place.
I don’t think so.
I’ve been an active LLVM contributor for several years, and I lead a team that packages and distributes LLVM and most associated sub-projects (including flang) for Fedora Linux, and a smaller sub-set (not including flang) of sub-projects for Red Hat Enterprise Linux.
I’m also the LLVM Release Manager, and I have a great deal of interest in ensuring that we are releasing high-quality code in all of the LLVM sub-projects.
I don’t have a lot of knowledge about flang’s internals, but I am one of the flang package maintainers in Fedora Linux. I have also read every comment on the Initial Discussion and Pitch Thread.
LLD is a linker from the LLVM project that is a drop-in replacement for system linkers and runs much faster than them. It also provides features that are useful for toolchain developers.
I don’t know if lld has aspirations to replace ld.
While Classic Flang is not an LLVM project, it is an active downstream LLVM project. For Fortran users, I don’t want to introduce a conflicting name until the compiler is actually competitive.
Personally, we replaced the NVIDIA C compiler with a newer version based on a different code base. The executable name was pgcc. During the transition, we introduced the new version as pgcc18 and introduced an alias for the old version as pgcc14. After pgcc18 was a suitable replacement for pgcc, we changed the alias so that pgcc was pointing to pgcc18.
That isn’t comparable I believe: the way it works for Linux in general is that you have binaries like ˋld.lld, ˋld.gold, … on the machine and /usr/bin/ld is a symlink to the actual linker.
Or another way to say it: ld is not a project, it is a conceptual « service » on Unix, like ˋcc` provides « a c compiler »
That is a reasonable strategy for a migration within the same project, I am not entirely sure I see a direct translation to flang: that is within the LLVM repo there is no other flang that we need to avoid conflicting with like in your example.
I am not sure either about the status and the plan for whatever provided a flang binary today.
What is the long term plan? Is flang gonna be renamed in any way?
Classic Flang is used in several downstream commercial projects like the AMD, Arm and Huawei compilers, and continues to be maintained, but the plan is to replace Classic Flang with the new Flang in the future.
I suppose one of the relevant questions here is: Has the future arrived?
Classic Flang is a fine compiler in its own right. For reasons detailed in my lightning talk, we decided to abandon it in favor of LLVM Flang (aka “f18”); chief among those was the difficulty that we were having extending the data structures to handle modern Fortran.
Right now, Classic Flang has more breadth than LLVM Flang. Chances are that an existing Fortran program will work fine with Classic Flang but it’s likely that the same program would trigger some “not-yet-implemented” messages when run with LLVM Flang.
LLVM Flang is more robust than Classic Flang. The front end can handle almost any program that we throw at it. Language features are implemented deeper and better when measured by objective testing.
LLVM Flang lags in lowering and code generation. That’s where the “not-yet-implemented” messages are generated. What is implemented is very robust and what isn’t implemented is tracked in a public spreadsheet.
For example, Classic Flang compiles the SPEC 2017 benchmarks and the runtime performance is very good. LLVM Flang can’t compile all of SPEC 2017 because of several “not-yet-implemented” features. Also, for those benchmarks that can be compiled, sometimes performance is bad.
The performance issues are being addressed as part of the HLFIR work that has been mentioned elsewhere. For NVIDIA’s part, most of our effort is being directed to completing lowering to HLFIR, FIR, and MLIR.
So if you want to compile and execute real Fortran programs, the future hasn’t quite arrived.
That isn’t comparable I believe: the way it works for Linux in general is that you have binaries like ˋld.lld, ˋld.gold , … on the machine and /usr/bin/ld is a symlink to the actual linker.
Or another way to say it: ld is not a project, it is a conceptual « service » on Unix, like ˋcc` provides « a c compiler »
I understand your point. If we extend this to flang, as a service to provide a Fortran compiler, then LLVM Flang isn’t ready to do the job yet.
Is flang gonna be renamed in any way
Yes. As I wrote in my first reply, I support the renaming. I do not support doing the renaming now but instead wish to wait until LLVM Flang is more mature. To me, this means re-evaluating after the HLFIR work is finished.
Sure, nobody claimed that LLVM flang is feature complete, but I’m not sure why it is relevant: ld.lld shipped very early while not being complete. It wasn’t named differently until it was ready.
I also don’t think this connects directly to my initial question about “finding a precedent” of any project that would have followed the logic and principles you suggest for LLVM flang, as far I can tell.
To clarify: I was asking about “classic flang”: what is it gonna be renamed to and is this renaming coordinated with the renaming of flang-new to flang?
We should implement this proposal without any further delay.
We all agree that the compiler driver executable in LLVM Flang should be called flang rather than flang-new. The only thing that we can’t agree on is the timing for this. There are two views:
Let’s rename as soon as possible - why wait?
Let’s wait till certain quality criteria are met. Once these are met, we can rename the driver.
Personally, I’ve always found the criteria for Option 2. too vague. We have effectively been discussing the renaming of the driver for almost a year now [1] - how much progress has been made towards Flang’s “readiness”? No doubt a great deal - LLVM Flang is a very active sub-project with tons of great contributions every week. However, have any metrics been defined and documented to help us understand how much work is left to reach this “readiness”? I am not aware of any [2].
My view is that either the renaming happens today or we will be waiting a few more years. By which time, many contributors might feel discouraged and will have left the project (let’s not forget that we should consider the perception within as much as outside our community). Also, if we wait for too long, people might simply get used to the current name, flang-new, and reject the idea of renaming altogether (e.g. to avoid having to refactor their build scripts and/or to change their habits).
No.
I have been making regular contributions to upstream LLVM for ~3 years. I have also contributed various tutorials dedicated to LLVM and its sub-projects (e.g. at EuroLLVM 2016 or as out-of-tree projects on GitHub).
I’ve authored, helped with or reviewed most of key functionality within flang-new. I used to chair a bi-weekly community call to discuss and to co-ordinate the driver development. I’ve also sent multiple RFCs to llvm-dev, cfe-dev, flang-dev and Discourse to discuss the design with the community. I have read this proposal in great detail and fully support it.
I hope that this helps. Flang is an amazing project - it would be great to resolve this soon.
-Andrzej
[1] First patch that attempted to rename flang-new (authored by me): ⚙ D125788 [flang][driver] Rename `flang-new` as `flang`
[2] Various definitions of “readiness” have been discussed, but what’s really missing is a clear and fixed metric that’s publicly visible and tracked.
The initial commit of the new MachO linker had its final name from day one despite its limited capabilities. I support the renaming, but the webpage should clearly state the supported features, i.e. Fortran 77 is fully supported.
