[llvm-dev] RFC for f18+runtimes in LLVM
James Y Knight via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 25 19:05:20 PST 2019
On Mon, Feb 25, 2019 at 5:46 PM Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
If there are such features that ought to be added to the support libraries
in LLVM for better C++17 support, then they can indeed be added, with an
appropriate #ifdef on language version, no?
The primary reason that I think it makes sense to allow f18 to require
C++17 is that this will be a _temporary_ divergence -- the rest of the LLVM
project will certainly move to require C++17 as well at some point
relatively soon. Any C++17-specific improvements made to llvm common
libraries will be useful for the rest of LLVM too.
I don't know what the expected timeline of f18 completion is, nor would I
like to predict excatly how long it'll be before LLVM might start requiring
C++17, but it certainly seems possible that LLVM might be ready to require
c++17 before f18 is even finished.
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.
Even if a decision is made to rewrite parts of the code in order to not
rely on C++17 features, I don't think that the initial import of the
project ought to be tied to that task being completed. More generally, I
think the prerequisite to merging it should be having an agreed-upon target
state and an understood path on how to reach that state, rather than the
code actually being _in_ that state already. Merging sooner is generally
better than waiting and merging later.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev