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

[Michael Spencer via llvm-dev]

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.

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