[llvm-dev] Flang landing in the monorepo - next Monday!

[Finkel, Hal J. via llvm-dev]

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