[llvm-dev] RFC for f18+runtimes in LLVM

[JF Bastien via llvm-dev]

> On Feb 26, 2019, at 4:07 PM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Mon, Feb 25, 2019 at 7:05 PM James Y Knight <jyknight at google.com <mailto:jyknight at google.com>> wrote:
> On Mon, Feb 25, 2019 at 5:46 PM Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto: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 <mailto: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:
> 
>  
> 
>   https://github.com/flang-compiler/f18/blob/master/documentation/C++17.md <https://github.com/flang-compiler/f18/blob/master/documentation/C++17.md>
>  
> 
> 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 libraries.
> 
>  
> 
> 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 projects.
> 
> 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.
> 
> How would we even test these changes on different platforms? Our current bots won't test it, I don't want two sets of bots, and upgrading all of the bots seems like most of the work to get to C++17.
>  
> 
> 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.
> 
> If we have a good reason to believe that's the case, fine. But currently, my suspicion is that F18's timeframe is much more definite.
>  
> 
> 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 LLVM.
> 
> 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.
> 
> Sure, I'm happy for the work to match the rest of LLVM to happen "in tree", but until then I think it should be disabled-by-default in the CMake build and not expected that folks update it when changing APIs etc. Similar to what we do w/ experimental targets. 

Developing F18 in-tree but off by default, like with experimental targets, seems fine to me. It’s experimental, and I don’t expect them to get tested by bots (unless those bots do extra work). Then they can use C++17 all they want, and when they’re close to done we’ll have clarity on whether LLVM would actually move to C++17. If not they’d have to downgrade to C++14, if LLVM is ready (or almost ready) then F18 is fine (they can even pitch in and help move to C++17 by then).

This is especially true if, for now, they don’t use any LLVM infrastructure (including ADT). As the project matures in-tree I’d expect them to try to use ADT more. That might break them, and then we can have a discussion: make ADT work well with C++14 and C++17, or force F18 to do extra work (which they already do!). If anything, having the F18 folks use ADT might ease the migration to C++17.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190226/8b835439/attachment.html>