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

[Chandler Carruth via llvm-dev]

On Tue, Feb 26, 2019 at 3:41 PM Michael Spencer <bigcheesegs at gmail.com>
wrote:

> On Mon, Feb 25, 2019 at 2:45 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.
>>
>> 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.
>>
>>
> lld used C++11 before the rest of LLVM switched over without issue.
>

I don't 100% agree -- we did end up with a bunch of support library
components in LLD that had to be migrated back to LLVM. =/ The story with
LLDB had more issues.

It may have been small enough and limited in time enough to not become a
large problem for LLD, but it still isn't something I'd like to repeat.

If we had some super concrete timeframe for when the rest of LLVM would
switch to C++17 (again, we've only even discussed C++14 so far!), that
might help. But currently, I think this is going to cause divergence
without benefit.

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