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

[Chandler Carruth via llvm-dev]

On Mon, Feb 25, 2019 at 7:05 PM James Y Knight <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> 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:
>>>
>>>
>>>
>>>
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190226/ae0a0698/attachment.html>