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

LLVM Project
33

Hi Everyone,

We had a productive call with @rouson, @everythingfunctional, @sscalpone, @psteinfeld and myself on June 5, 2023. I took a few incomplete notes on the discussion, which was wide ranging. A few things came up:

  • There is a great concern about getting LLVM’s flang out to many people to build distribution and a user base, but also a great sense of responsibility to make sure we do so in a way that doesn’t lead with bad impressions. The sense of responsibility felt to the user community is powerful and I love it.
  • LLVM’s flang is somewhat early (seems like a 0.8 level of maturity) and undergoing architectural changes, including major changes to the lowering strategies.
  • it has come a long way: it now generates “error: unimplemented” errors instead of just doing the wrong thing, and the number of known miscompilations is greatly improved.
  • That said, there are a large number of important code bases it cannot compile yet, including SPEC, netcdf, hdf5 and others. This doesn’t make it useless, but it isn’t as widely useful as folks want.
  • No one on the call wants the existing “flang” in package managers (like homebrew, freebsd, rpm, etc) to get silently replaced with LLVM’s flang, because that will break existing users. We want increased and new distribution, but don’t want to break anyone.

After discussing a number of different aspects of the project, we came to a pretty actionable proposal that everyone agreed with:

  1. We should remove the need for the -flang-experimental-exec flag. There’s no need to hide things to this level given the evolving maturity of LLVM’s flang. This will be an immediate improvement for all flang-new users.
  2. We should update the LLVM’s public flang web site to project an image of “still being in development”, and advertise a “0.8” level of maturity. The -v flag should also advertise this - it is completely ok for flang to have its own versioning that parallels the LLVM version number.
  3. We should rename the ‘flang-new’ driver to ‘flang’ in the LLVM monorepo, but only when the code matures a bit more. Please follow flang in discourse to track its status.
  4. We should start our own packaging efforts (it sounds like Brad will help take the lead around this) to package LLVM’s flang compiler into an “llvm-flang” package that can live parallel to the existing PGI “flang” package. When the LLVM flang compiler matures, we can look into it subsuming the existing “flang” package completely. I don’t know what the concrete versioning will be, but there is already precedent in clang (e.g. on a mac it reports itself as Apple clang version 14.0.0 (clang-1400.0.29.202)).
  5. We should look at various existing distributions of LLVM C++ compiler to make sure they don’t install the flang driver, or that they install it as “llvm-flang” until it matures. We don’t want users to accidentally be broken by a “/usr/bin/flang” overwrite just because the LLVM package is built and installed.

I want to thank the review managers for a balanced and thoughtful discussion on these topics. It is very clear that everyone involve has the success of LLVM’s flang project in mind and the friction we saw earlier was the result of different opinions on how to get the compiler out more people.

-Chris

8 Likes