Hi all,
I’m really sorry for the delay getting back to this, this happened to be an extremely busy couple months for me for other reasons. I see that this is a very pressing problem and is causing friction in the LLVM community, so I’m thrilled we’re using the decision making process. That said, in the future, I would appreciate it if we could all follow the process (specifically the "share a draft with Chris for feedback ahead of running the review): I didn’t find out about this until it was over a month in because I wasn’t following this section of the forum closely.
In any case, while I don’t think we will be able to resolve this overnight, I would like to get the review managers together for a zoom call - I’m sure all of our schedules are a mess, so a call on the weekend is probably the best. Could you each email me at “clattner” AT llvm.org with your availability for May 26/27/28?
In addition to a zoom, in order to encourage async discussion over the next week, I pulled together some notes from my reading of the proposal and the review thread. This is a quick summary intended to capture directional feelings from people and initial thoughts, I’d love to know if I got anything seriously wrong, and what people think about the comments I add.
Notes on Rename flang-new to flang
- Proposal Link + guide to LLVM Decision Making Process
- Reviewers in favor: @rouson, @everythingfunctional
- Reviewers opposed: @sscalpone, @psteinfeld
Core issues
Is “flang-new” aka “f18” is mature enough to be renamed “flang”? We have a bit of an unprecendented situation where an LLVM project is taking the name of an already established compiler. Everyone seems to want the older flang to fade away, but flang-new is not as mature and it isn’t clear when and what the criteria should be for that.
Secondary issues:
- How much does LLVM care about other ecosystem compilers? Shouldn’t it be up to users of these projects to decide whether to install flang-new, e.g. can’t they just use full paths to disambiguate?
- How do we handle identity confusion between different systems with the same name (e.g. what does some web page talking about “flang” mean?
- Should we reject future LLVM projects that take names already used in the ecosystem?
The macro issue is that this is perhaps the first time an LLVM project aims to replace an existing widely used compiler with the same name. Typically we introduce new names: clang vs gcc, pgcc vs gcc, lld vs ld/ld64, etc. This way you can have both side by side and not be confused. Mehdi points out that user’s end up with a symlink to pick an implementation, but that’s a “selecting an implementation” thing (another analog is xcode-select on macs), but each implementation still has distinct and easy to reason about identity.
Chris’ thought on the proposal itself before reading thread comments:
-
Proposal is two things: one is default -flang-experimental-exec on, and other is rename flang-new to flang.
==> Are there any objections to defaulting -flang-experimental-exec on? Maybe that is a good first small step in the right direction? -
Comment on motivation: Complains about status updates being “particularly well publicized, been relatively vague, etc” which seems unrelated to the name of the driver. Renaming the driver won’t cause less-vague or more publicized updates. I can see how there are barriers to adoption here though.
==> the proposal’s motivation should directly address the core issues that the proposal will address, not unrelated issues in the flang community. -
It is not clear to me that renaming the command line tool will increase the size of the audience or gain more developers. The proposal should clarify this if it is a goal.
-
Impact on Other Projects: Agreed there is no significant impact on other LLVM projects, but community members seem concerned about hybrid situations where there are other compilers named flang on the system. It isn’t clear how the LLVM community should weight those concerns though.
==> The proposal should address this issue head on and share the advocates view of why this the right thing despite this conflict. -
The proposal sort of skirts around the immaturity issues with flang-new - it has made tremendous progress but does not seem large scale production quality at the moment. What is the current state of development? Is “flang-new” development still vigorous and proceeding? Has a recent maturity cross-over point been reached which justifies the transition point? For opponents to this change, what do you think are the reasonable threshold for making a change? (this was addressed in comments on the thread).
==> The proposal should tackle these issues heads-on instead of avoiding sticky points.
I would love to see an updated draft of the proposal. I think that would help ratchet the discussion forward. This is the chance for the proponents of the proposal to directly address the opponents points, it should ideally be done so in the proposal itself.
Larger raised issues / comments:
-
jeffhammond: Argues we can provide a single driver named “flang” that takes a flag that picks the implementation.
==> Seems weird for LLVM project to provide an Uber-driver for other projects’ compilers. There are precedents for this (e.g. very early clang’s driver written in python did this) but that was with a new name and for other reasons. Fortran users seem to have many different compilers already and need to select them in their make files anyway. -
Old web sites refer to “flang” generically, and it unclear what compiler they are referring to.
==> This seems like a potentially huge issue to me, regardless of what “flang -v” says to a user on the command line, it is important to understand what compiler some documentation online is referring to. It would be great to address this head on in the proposal. -
tschuett: Flang-new web site could be improved to be more user-centric
==> I’m sure this is true, but doesn’t seem like the core issue. -
sscalpone: Criteria for doing the rename is when HLFIR lands.
==> It isn’t clear to me as a non-flang person why or what user-benefit this would provide, I’d love more explanation here as I’m not familiar with flang community or technical issues. Without a better understanding, I don’t see why an internal implementation detail of the implementation would be the gate, it seems like a more objective user-centric criteria like “builds all of spec and this other codebase” would be appropriate. -
mehdi_amini points out that clang was named that from the beginning despite being immature.
==> Seems not very relevant though given there were no other clang compilers to cause confusion. -
tstellar observes that we decided ‘flang’ was important enough to the LLVM project to take it into the mono repo in the first place, so we should give it its name.
==> Seems like a proxy for “why does the LLVM project care about other compilers in the ecosystem”? -
sscalpone points out that flang-new is not fully mature, cannot yet build SPEC 2017 and performance isn’t always there.
-
banach-space points out that setting criteria for rename leads to moving goalposts.
==> Maybe the criteria was never set right before? -
There are some very strong statements that “flang” is the only name that can be considered. It isn’t clear at all to me that is the case. We should consider this along with the other paths forward:
==> flung, fling,flong, fnf. We could follow gnu convention and name this “lfortran”, or even go back to f18 or some wholly new name.
==> This approach has the major benefit of making it much more clear “which flang” random things on the internet are referring to, and I’m sure would define away confusion when speaking verbally and when any individual team is planning migration from one thing to another.
Possible paths forward
Clearly needs more discussion, and I would like to get people together into another medium (e.g. Zoom) to do so. There are several paths to consider:
- Accept the proposal and don’t look back. I would love a better understanding from opponents of what harm accepting the proposal would cause the ecosystem.
- Reject the proposal for the time being, but set a much more clear criteria for when a transition should happen; could be feature driven, date driven, etc so developers don’t have moving goal posts.
- Rename flang-new to something other than “flang”. This would eliminate the long-term ambiguity problems and allow multiple implementations to coexist.
-Chris