[PITCH] Rename `flang-new` to `flang`

LLVM Project
1

I would like to invoke the Contentious Decision Making Process for what has become a controversial topic. I am hopeful that input from the broader LLVM developer community can help to resolve the issue. I have begun by writing a first draft of the proposal to hopefully facilitate the discussion.

Introduction

The current status of the driver for Flang is that it is named flang-new, and requires specifying the (undocumented) flag -flang-experimental-exec in order for it to produce an executable. It is proposed to change this such that flang-new -flang-experimental-exec can be used as just flang.

Motivation

For background, prior discussions on the topic can be found in a recent Discourse thread, an older Discourse thread, and a patch submitted nearly a year ago. A new patch has also been submitted, but has received no reviews or comments yet.

The motivation is that there are interested parties who would like to start trying out flang to see what it’s capabilities might be so far with respect to their codes. Thus far status updates for the project have not been particularly well publicized, have been relatively vague, and generally unclear, meaning the most direct assessment would come from just trying it. The current status means that they must either apply the proposed patch themselves or clearly explain to their users how to actually use it. These artificial barriers to use are exclusionary, are preventing the project from getting useful early feedback, are turning potential contributors away and giving potential new users a bad impression and poor experience.

Proposed Solution

A patch has been submitted to make the necessary change. The patch renames the driver from flang-new to flang, and removes the requirement for the flag -flang-experimental-exec to proceed with generating an executable. Doing this as a single step means that existing users will need to change anything relying on the current name and flag only once, and the sooner the change is made the fewer people will be impacted (we have fewer users now than there will be later).

Impact on Other Projects

This should have no impact on other LLVM projects, and will mean that any existing users of flang will finally be able to use it in the way it has always been expected and will be expected to be used going forward.

Frequently Asked Questions

Could this potentially turn new users away forever for whom the features they need from flang are not yet ready?

Discussions have addressed this concern as likely unfounded, and actually that there is potential it could actually encourage contributions from new users and drive engagement with a new community. Also, the current state is already giving potential new users a bad experience, so if such an experience was going to turn someone away forever, it likely already has.

Who will address new bug reports and feature requests as new users begin to try it out?

A team has offered to respond to new issues and serve as liaisons to the flang user community.

Alternatives Considered

Wait longer: The argument is that it is not ready for real users, and making this change could imply unrealistic expectations for new users.

Do this in phases, or as build options: The idea here would be that we gradually make it easier for more “advanced” users to try things out, so as not to overwhelm the current developers with feedback from new users all at once.

Neither of these alternatives would be ideal, as previously explained.

6 Likes
2

Hi @everythingfunctional,

Thank you for drafting this!

I am not that familiar with the process, but I think that we are missing “Review managers”:

  1. A group of either 2 or 4 community members are selected as “Review Managers” to help with the review, aiming to be representative of both sides of an issue. These people are proposed in the pitch document itself.

Also, CC @clattner :

  1. Chris takes a look, gives high level guidance to improve the quality of the proposal, approves (or suggests changes to) the Review Manager list, and decides whether it makes sense to run.

HTH,
-Andrzej

3

Happy to do it, as I have interest in seeing it happen. I am not familiar with the process either.

I missed that part, since it is listed in the next step. Unfortunately, I’m not sure I would know who to select aside from those I’ve already selected as reviewers for the patch, and they (unfortunately) haven’t seen fit to weigh in. My hope was that this would bring in new eyes. If anyone could suggest “Review managers”, I’d greatly appreciate it.

4

Hi @everythingfunctional, thank you for raising this. I happened to be traveling last week so didn’t notice this until now. I’m happy to help drive this.

Are there actually “two sides” to this issue, or is it just a matter of no one wanting to be bold enough to say “let’s do it!” I don’t see any dissent on your patch thread for example.

-Chris

5

@clattner Most of the discussion was in this thread.

6

Hi @clattner , thanks for joining in. All discussion has taken place in a prior patch and a couple Discourse threads.

I think all the prior discussions have led to people being hesitant to comment on my patch (i.e. outspoken opposition has chilled supporting speech). But, if a lack of rejection in the official channel (my new patch) could be seen as acceptance, I’d be more than pleased about that.

7

Ok, I skimmed some of the threads, but I think I need a bit more background to understand the issue here.

It sounds like there are two things named flang - an “old flang” and this patch is proposing having the LLVM Flang project take over that name - a “new flang”? Is this correct?

If so, what is the old flang, how is it distributed, and when does a user end up with both of them on the same system?

Edit: Turns out that I can use a search engine, quoting this page:

“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”; see https://flang.llvm.org/), which has been part of the LLVM project since 2020, although both are developed by the same community. It is also unrelated to other projects of the same name, such as GitHub - llvm-flang/flang: Fortran Front-End and https://github.com/isanbard/flang.”

So this sounds like a discussion about how mature llvm flang is and whether it is time to switch it on by default?

-Chris

8

At present, there is nothing in the LLVM project that can be built named flang. There used to be until relatively recently, but it was a wrapper script that has been renamed to flang-to-external-fc. It basically just used the new Fortran parser, but called a separate compiler (default being gfortran) to actually do the compilation. Also, I don’t believe that flang is built by default (i.e. you have to specify in the cmake command -DLLVM_ENABLE_PROJECTS="clang;mlir;flang;lldb"), and this doesn’t propose to change that. I just want flang to be called flang, and not require a secret flag to use.

1 Like
9

Yes, Chris. That’s it in a nutshell.

In the linked discussion, I think the reasons to hold back are clear. Let me know if these bear repeating or need further expansion.

Everything that @everythingfunctional needs is available in llvm-project for a downstream implementation of this request. It’s not clear to me why this change needs to be made in llvm-project now.

- Steve

1 Like
10

This is exactly where the disagreement lies. I contend that it has little to with how mature llvm flang is, and I’m not proposing to “switch it on by default”. I’m proposing to remove a (partially) undocumented barrier to entry for potential new contributors (namely early adopters/testers).

While this is true, I’m clearly not the only one who’d like to do it, (i.e. this post), so why make everyone manually apply it themselves?

Because the longer we wait, the more people it will negatively impact once the change is finally made.

I’m happy to re-litigate the discussion here, but I believe most of my points have been made in the prior thread.

1 Like
11

Sorry for not chiming in earlier - I was also traveling.

That’s not how I see it. Yes, we’ve had an extensive discussion about the maturity of LLVM Flang. However, @everythingfunctional and I argue that the name of the only existing compiler driver in LLVM Flang should be orthogonal to that. In particular:

  • the compiler driver in LLVM Flang should be called flang,
  • the maturity of LLVM Flang should be communicated through clear documentation, blog posts and community engagement rather than the driver name.

The driver in LLVM Flang can generate executables - folks have been using it build Spec 2017 and other benchamrks for quite a while now. So it definitely feels “mature enough”. Also, Clang has become an extremely successful project without needing:

  • clang-new -flang-experimental exec <src-file>, instead of
  • clang <src-file>

to generate executables. Why wouldn’t similar openness towards our users not work for LLVM Flang?

I’m happy to provide more context (I spent some “quality time” with Flang’s compiler and frontend drivers) and to review @everythingfunctional patch once there’s an agreement for the renaming.

-Andrzej

4 Likes
12

As a status check, not all of the SPEC 2017 benchmarks are working yet – wrf and pop2 still have issues. On Spec 2006, tonto is still open. There was a concerted effort from the community to focus on issues related to SPEC 2017 to clear the path for others who are working on performance-related features, such as inlining array intrinsics.

The current status of “TO DOs” is recorded in the spreadsheet F18 "not yet implemented" - Google Sheets. My takeaway from the list is that several widely-used features of Fortran are not yet implemented. That’s why I recommended Classic Flang in the thread for users today. Classic Flang still has a robust and active development community.

The reasons for replacing Classic Flang with LLVM flang are explained in the lightning talk 2019 LLVM Developers’ Meeting: S. Scalpone “Flang Update”.

My recommendation is to reopen this discussion after [RFC] Add higher level operations in FIR lands.

13

From a process stand point. I don’t think this thread is meant for giving feedback on the technical issue, but it’s for selecting the review managers and giving feedback on the written pitch itself. Discussion will take place on the [Proposal] thread.

14

I am bit confused: is “classic Flang” this project GitHub - flang-compiler/flang: Flang is a Fortran language front-end designed for integration with LLVM. ?
Why does it impact how we decide name the flang driver during the development of the compiler in the LLVM project?
You can recommend users to use “classic flang” if they need features not supported by flang, but that shouldn’t prevent LLVM Flang from starting its live.

3 Likes
15

I can’t help feeling the criterion given by those opposed to making this change have been intentionally vague, moving goal posts, making them effectively unachievable in any predictable time frame. This is the first I’m hearing of

I wonder what will be put forth as the reason to delay next? Further, the initial criterion proposed on the first patch were themselves moving goal posts with no publicly visible status:

My proposal is:

If the compiler compiles it, it ought to run.
If the compiler can’t compile it, it ought to clearly say why.

  1. All tests of legal Fortran that compile & link must also execute correctly (which excludes tests that expect to catch a problem at runtime)
  2. For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature

My preference is to use the NAG test suite. It is not freely available.

For number 1, what are the chances that as more legal Fortran becomes compilable and linkable, that it necessarily executes correctly. I.e. items which are satisfied under category 2, may move to unsatisfied under category 1. As new Fortran standards are released (one is coming out this year), there will be a growing list of unsupported that aren’t satisfied under category 2. Not to mention, it’s effectively demanding there be no Internal Compiler Errors (ICE), as one can almost always come up with new ways of combining/using unsupported features that haven’t been thought of. I don’t know of any compiler that has ever even come close to having no outstanding known ICEs, let alone none period.

Why are we using these unattainable, moving goal posts to dictate the name of the flang driver?

3 Likes
16

I’m still a bit new to this process, but fair point. How do we go about selecting the review managers?

1 Like
17

None.

I only bring it up because one of the reasons given in favor of the renaming (this post) was to allow a FreeBSD maintainer to build flang. My advice to the maintainer was to ship Classic Flang.

2 Likes
18

The documentation says to pick 2 to 4 people that are representative of both sides of the issue. Just looking at who was chosen for review managers in the last pitch it seems like a good start might be you and @sscalpone. If you decide to expand it to 4, it might be good to pick some people who have a little less invested in the decision who can also help to moderate the proposal discussion. I’m happy to volunteer as a review manager if you do want to make it 4.

19

I think it should at least not be just me and @sscalpone. We’ve already been arguing it out for weeks. That’s the whole reason I invoked this process. I was kind of hoping to get some fresh perspectives. If it just ends up being the same group of us arguing all over again, I don’t know if it will have bought us much.

If I were picking those most active in the discussion so far, I’d go with myself and @rouson on the pro side, @sscalpone and @klausler on the con side. That said, we might not be particularly good candidates for

facilitating and moderating the discussion - helping to keep the discussion on-topic and civil, without trying to overtly influence the discussion

With that in mind, I think we need some more neutral parties. @tstellar , if your willing to serve as a review and have a possible 2nd in mind, I think that would be better.

2 Likes
20

Can we bring the level of heat down, please? Not everyone who disagrees is arguing in bad faith or moving the goal posts. HLFIR was mentioned in the previous thread almost a month ago.

3 Likes