llvm dev - Feb 2019 - RFC for f18+runtimes in LLVM

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>

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>

On Tue, Feb 26, 2019 at 4:05 PM Chandler Carruth <chandlerc at gmail.com>
wrote:
> 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.
>
The support code that ended up in lld instead of libSupport ended up there
mostly because it wasn't viewed as useful to the rest of LLVM, not because
of language version.  I wasn't aware of any LLDB issues as I don't
follow
it that closely.

- Michael Spencer

>
> 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/7d2019ff/attachment.html>