llvm dev - Jan 2020 - Flang landing in the monorepo - next Monday!

On Mon, 13 Jan 2020 at 06:50, Eric Christopher <echristo at gmail.com>
wrote:
> I don't really consider this addressed without a plan of action (before
merge) that contains a list of standard llvm support libraries that would be
used in addition to things being removed (pretty much all use of C++ c* headers
and more?) as well as staffing and approximate ETAs.
Agreed.
> I think waiting until after the llvm 10 branch would probably be best at
this point. That will give a lot of time for cleanup and to make f18 a much more
reasonable "preview" including code generation in a forthcoming
release in about 6 mos.
Before this thread, I thought the progress of F18 was much further
than it is. My initial comments assumed it.

Now, I am surprised it's not using LLVM API yet (a clear and
consistent complaint of the previous one), as well as having its own
driver, test infra, etc.

The lack of C++ compatibility may look small now, but once we want to
move to a newer standard, Flang will be the bottleneck. In a monorepo,
these things are even more important.

F18 was supposed to be a whole new front-end, from scratch, but it
looks to have carried along many of the previous projects' flaws.

I really wouldn't like to see the next release with such wide range of
incompatibilities.

So, +1 to both waiting the release branch as well as a concrete plan
with a deadline to address all the critical issues before the next
release.

cheers,
--renato

On 2020-01-13, Renato Golin via llvm-dev wrote:
>On Mon, 13 Jan 2020 at 06:50, Eric Christopher <echristo at gmail.com>
wrote:
>> I don't really consider this addressed without a plan of action
(before merge) that contains a list of standard llvm support libraries that
would be used in addition to things being removed (pretty much all use of C++ c*
headers and more?) as well as staffing and approximate ETAs.
>
>Agreed.
>
>> I think waiting until after the llvm 10 branch would probably be best
at this point. That will give a lot of time for cleanup and to make f18 a much
more reasonable "preview" including code generation in a forthcoming
release in about 6 mos.
>
>Before this thread, I thought the progress of F18 was much further
>than it is. My initial comments assumed it.
>
>Now, I am surprised it's not using LLVM API yet (a clear and
>consistent complaint of the previous one), as well as having its own
>driver, test infra, etc.
>
>The lack of C++ compatibility may look small now, but once we want to
>move to a newer standard, Flang will be the bottleneck. In a monorepo,
>these things are even more important.
>
>F18 was supposed to be a whole new front-end, from scratch, but it
>looks to have carried along many of the previous projects' flaws.
>
>I really wouldn't like to see the next release with such wide range of
>incompatibilities.
>
>So, +1 to both waiting the release branch as well as a concrete plan
>with a deadline to address all the critical issues before the next
>release.
>
>cheers,
>--renato
See another thread: there are several competing Fortran frontends based on LLVM

http://lists.llvm.org/pipermail/llvm-dev/2020-January/138194.html

I hope we can wait for the community to evaluate these implementations
and think how to collaborate before rushing and making one "official".

On 1/13/20 8:25 PM, Fangrui Song via llvm-dev wrote:
> On 2020-01-13, Renato Golin via llvm-dev wrote:
>> On Mon, 13 Jan 2020 at 06:50, Eric Christopher <echristo at
gmail.com>
>> wrote:
>>> I don't really consider this addressed without a plan of action
>>> (before merge) that contains a list of standard llvm support 
>>> libraries that would be used in addition to things being removed 
>>> (pretty much all use of C++ c* headers and more?) as well as 
>>> staffing and approximate ETAs.
>>
>> Agreed.
>>
>>> I think waiting until after the llvm 10 branch would probably be 
>>> best at this point. That will give a lot of time for cleanup and to
>>> make f18 a much more reasonable "preview" including code
generation
>>> in a forthcoming release in about 6 mos.
>>
>> Before this thread, I thought the progress of F18 was much further
>> than it is. My initial comments assumed it.
>>
>> Now, I am surprised it's not using LLVM API yet (a clear and
>> consistent complaint of the previous one), as well as having its own
>> driver, test infra, etc.
>>
>> The lack of C++ compatibility may look small now, but once we want to
>> move to a newer standard, Flang will be the bottleneck. In a monorepo,
>> these things are even more important.
>>
>> F18 was supposed to be a whole new front-end, from scratch, but it
>> looks to have carried along many of the previous projects' flaws.
>>
>> I really wouldn't like to see the next release with such wide range
of
>> incompatibilities.
>>
>> So, +1 to both waiting the release branch as well as a concrete plan
>> with a deadline to address all the critical issues before the next
>> release.
>>
>> cheers,
>> --renato
>
> See another thread: there are several competing Fortran frontends 
> based on LLVM
>
> http://lists.llvm.org/pipermail/llvm-dev/2020-January/138194.html
>
> I hope we can wait for the community to evaluate these implementations
> and think how to collaborate before rushing and making one
"official".

I elaborated on this in the other thread, but I think that we should 
also be clear about this: there are indeed multiple active projects that 
have at least some version of their source code and development in the 
open, and none of them are complete, but importantly, only one of them 
has committed to continuing development as part of the LLVM community. 
The developers of the Flang/f18 project are aware of these other 
efforts, but aside from looking at what others have done for general 
guidance, I think that there's little we should do in this regard unless 
the authors of these other projects propose to contribute 
essentially-conflicting code. In that case, we have decisions to make, 
and I don't think that would necessarily be a bad problem to have (in 
fact, I've encouraged it), but right now, that's not a problem we have.

The "rush" here, from my perspective, is to move the development of 
Flang into the LLVM community. Once there, we'll all be in a better 
place to evaluate -- and effect -- design decisions and other aspects of 
the implementation. We can, of course, even completely replace parts of 
whatever code we merge in. I've explained to those working on the 
Flang/f18 project that everything is subject to post-commit review, de 
novo, once here. We should, however, build a developer community here, 
instead of having a diffuse, smaller set of projects elsewhere.

I'll add that one of the things that makes me comfortable with using the 
Flang/f18 as the base is the team of active developers, which includes 
several Fortran experts in addition to younger people, and the way 
they've applied that experience to proceed methodically through the 
development done so far. Starting with the Fortran preprocessor, for 
example, which is essential but non-standard, how should it work? A 
survey was conducted of many compilers and the results documented 
(https://github.com/flang-compiler/f18/blob/master/documentation/Preprocessing.md
- this is the best document on what the Fortran preprocessor should do 
that I've ever seen). Then lexing and parsing, which was then round-trip 
tested on a huge collection of existing Fortran source code. Then 
starting on semantic analysis, also tested using a huge test suite. 
Concerns here have been raised about better use of LLVM support APIs, 
etc. - all legitimate concerns and concerns that will be addressed - but 
my confidence that the developers here are committed to producing a 
frontend of the highest production quality is very high.

Thanks again,

Hal

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

On Mon, Jan 13, 2020 at 6:26 PM Fangrui Song via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2020-01-13, Renato Golin via llvm-dev wrote:
> >On Mon, 13 Jan 2020 at 06:50, Eric Christopher <echristo at
gmail.com>
> wrote:
> >> I don't really consider this addressed without a plan of
action (before
> merge) that contains a list of standard llvm support libraries that would
> be used in addition to things being removed (pretty much all use of C++ c*
> headers and more?) as well as staffing and approximate ETAs.
> >
> >Agreed.
> >
> >> I think waiting until after the llvm 10 branch would probably be
best
> at this point. That will give a lot of time for cleanup and to make f18 a
> much more reasonable "preview" including code generation in a
forthcoming
> release in about 6 mos.
> >
> >Before this thread, I thought the progress of F18 was much further
> >than it is. My initial comments assumed it.
> >
> >Now, I am surprised it's not using LLVM API yet (a clear and
> >consistent complaint of the previous one), as well as having its own
> >driver, test infra, etc.
> >
> >The lack of C++ compatibility may look small now, but once we want to
> >move to a newer standard, Flang will be the bottleneck. In a monorepo,
> >these things are even more important.
> >
> >F18 was supposed to be a whole new front-end, from scratch, but it
> >looks to have carried along many of the previous projects' flaws.
> >
> >I really wouldn't like to see the next release with such wide range
of
> >incompatibilities.
> >
> >So, +1 to both waiting the release branch as well as a concrete plan
> >with a deadline to address all the critical issues before the next
> >release.
> >
> >cheers,
> >--renato
>
> See another thread: there are several competing Fortran frontends based on
> LLVM
>
> http://lists.llvm.org/pipermail/llvm-dev/2020-January/138194.html
>
> I hope we can wait for the community to evaluate these implementations
> and think how to collaborate before rushing and making one
"official".
>
I believe we're already long past this stage:
- [llvm-dev] RFC for f18+runtimes in LLVM
<https://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html>
- [llvm-dev] [RFC] Renaming f18....
<https://lists.llvm.org/pipermail/llvm-dev/2019-April/132019.html>
- [llvm-dev] f18 is accepted as part of LLVM project!
<https://lists.llvm.org/pipermail/llvm-dev/2019-April/131703.html>

As far as I understand, we're now at the stage of the process where
we're
looking to bring the development of flang in-tree so that all parties
interested in Fortran support in LLVM can collaborate. My understanding is
that the f18 codebase has been accepted as the basis for starting this
collaboration last April, but that does not preclude any change (including
major rewrites) to happen in-tree.
After all, Chris wrote that *none of the subsystems in LLVM are really good
until they have been rewritten at least once
<https://www.aosabook.org/en/llvm.html#footnote-8>* ;)

Best,

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200113/b790563c/attachment.html>