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

Petr Penzin via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 1 05:12:04 PST 2019


Following up on my earlier email. If there is a commitment to checking 
in f18 already, feel free to disregard it. I went and took a little bit 
closer look at the sources and want to share some of the findings in 
case if anyone is interested. Disclosure: I contribute to Fort 
<http://fort-compiler.org/> (fort-compiler.org), which is the fork of 
the front-end David Greene mentioned.

 From Stephen's announcement:

> At this point, we have documented and implemented a healthy subset of 
> the compiler for symbol tables and scoping, name resolution, USE 
> statements and module files, constant representation, constant folding 
> and much of declaration, label and expression semantics. The parser 
> handles all of Fortran 2018 and OpenMP 4.5 and implements a 
> Fortran-aware preprocessor. The Fortran control flow graph (CFG) is in 
> review now.  We continue to update other documentation, such as the 
> style guide and runtime descriptor design.
>
Currently it looks like only the parser is /partially/ implemented in 
f18, there is no code generator (via LLVM or otherwise) and, obviously, 
no object output. For that reason and due to the condition of its test 
suite it is impossible to reliably assess the state of Fortran 18 
support (thought it does look like a fair amount of effort went into 
it). State of OpenMP support actually got me a bit puzzled, more on that 
below.

As I understand the announcement, f18 is intended to be used or merged 
with Flang sources at some point, but that still does not explain how it 
would integrate with LLVM, since Flang does not seem invoke LLVM 
directly either (it used to produce LLVM IR as text files). Because of 
this, it is likely that its code generator component would have to be 
written from scratch. It is also unclear if and how it would provide the 
library API which has been announced.

A bit about the test suite -- I looked at the Fortran (regression) part 
of it (as opposed to unit tests, which hopefully are a relatively simple 
affair). Maybe nitpicking, but despite "handles all of OpenMP 4.5" 
statement in the announcement there seem to be only two references to 
OpenMP in tests. Most of the regression tests are challenging to 
understand -- some list all expected output upfront, some of the 
expected output is not particularly human-friendly. Maybe I am used to 
Clang's test suite, but it is unclear to me what each file is testing. 
Also, regression testing relies on a set of shell scripts to do some of 
the output checking.

My worry here that it would actually take years to develop f18 into an a 
working compiler, in which case there might be other options worth 
considering for a Fortran front-end. In my opinion (and this /may/ be a 
matter of personal preference) a healthier subset of the compiler would 
be more of an end-to-end subset of it -- something that can be tested as 
a full product while it is being developed. And then there is also the 
argument for reusing Clang tooling, which David Greene keeps making, 
though that idea does not seem to get a lot of interest.


Best,

Petr

On 2/27/19 1:55 PM, Chris Lattner via llvm-dev wrote:
> On Feb 25, 2019, at 10:06 AM, Stephen Scalpone via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> We're committed to developing LLVM's Fortran frontend for years to 
>> come, and together with other members of the LLVM community (e.g., 
>> ARM, US Dept of Energy) would like to do so as part of the LLVM project.
>
> This is super exciting Stephen, congratulations to you and everyone 
> working on f18.  I’m very excited to see this happening and am 
> thrilled about the approach you are taking.
>
>> 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
>>
>> 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.
>
> I personally see no problem or concerns with this at all.  This is a 
> new project and the worst case is that f18 comes up with some really 
> cool stuff that the rest of the LLVM project would love to share, but 
> that can’t be done until it is refactored to not use c++11.  If/when 
> that comes up, we can deal with it on demand.  I don’t see any 
> particular reason to block f18 from joining the project because of 
> that speculative concern.
>
> -Chris
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190301/bd83168e/attachment.html>


More information about the llvm-dev mailing list