[llvm-dev] RFC for f18+runtimes in LLVM
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 25 14:45:28 PST 2019
On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> * The current f18 code will be committed to the new LLVM subproject. The
> f18 code is a set of libraries that implements the Fortran compiler.
Awesome. This is an important aspect of the design of LLVM projects IMO ->
they build their functionality primarily as re-usable libraries, and then
expose that in useful command line utilities.
> The f18 compiler source code complies with most of LLVM's coding
> guidelines; however, the code uses several C++17 features. We've
> documented our use of C++17 here:
> In particular, the parse tree and the lowered forms of expressions and
> variables are defined in terms of C++17 std::variant. Most of the
> compiler uses C++17 std::visit to walk these data structures.
> It’s possible to reimplement the most important functionality of
> std:variant as a subset class, say llvm:variant; however, variant gets
> its power from the C++17 features generic lambdas and parameter pack
> expansion on “using”. Without these C++17 features, use of variant would
> be impractical.
> Our thinking when we started was that llvm would adopt C++17 before
> mid-2020, which lines up with our projected completion date. If we were to
> adopt C++11 or C++14, we would likely create substitutes for these classes,
> certainly at a cost of calendar time and perhaps type safety and notational
> convenience. One of our principles is to take advantage of the standard
> library as much as possible, so casual readers will better understand our
> code and so we avoid the time and bugs associated with writing class
> Our request would be to get a waiver for the C++11 requirement based on
> the fact that we're skating to where the puck will be. In the meantime,
> because F18 only exists as a stand-alone program, early adopters would
> still have a useful parser and analyzer for Fortran.
Hold on, either it is a collection of libraries or it is a stand-alone
program. It can't really be both?
Generally, I think the idea that diverging from the rest of the project
here is low-cost for a subproject isn't supported by experience with other
Notably, it has a strong tendancy to create tension. You want some ADT or
support library in LLVM to work well with your C++17 code. But it is C++11.
Every time this has been done in the past, the result has been that
generically useful tools and libraries get added to the subproject rather
than to LLVM as a whole.
So FWIW, I'd be really opposed to this. Instead, I think that F18 should
have rich libraries, and develop them exactly the same way as the rest of
We're getting close to switching to C++14, so maybe due to timing, you
could merge F18 when that happens?
Ultimately, I think you either need to raise the LLVM base language version
or lower the F18 one so that they match when merged IMO. Anything else I
think will hamper integration with the larger project.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev