What is the exact difference between LLVM Flang and LFortran?

I somehow missed this thread. I am the original author of LFortran. It turns our LFortran and the new Flang started almost the same month a few years ago. For a while we did not know about each other, but even after I met many Flang developers in person, it is unclear how we can collaborate more tightly because the projects have different goals and priorities:

  • LFortran is interactive, so it can parse more than the standard Fortran, it can also parse loose expressions and statements. Flang cannot (currently) do that as far as I know.

  • One of the requirements for LFortran is a very fast (as fast as possible) compilation speed, which guides the internal data structures to be as efficient as possible.

  • LFortran has multiple backends. That has been the design from the beginning to not be tied to LLVM. It can use it of course (it is the default backend currently), but we also have a C++ translation backend, direct x86 machine code generation backend (very fast compilation speed, but no optimizations) and we plan many other backends (Python wrappers, Julia translation, MLIR backend, etc.). LFortran is not tied to, nor part of LLVM for this reason.

  • The previous point guides a design decision to transform AST (Abstract Semantic Tree) to ASR (Abstract Semantic Representation), which is a standalone representation, but it does not lose any Fortran semantics, everything is figured out and it is the starting point of our backends, makes it very easy to maintain a backend. ASR also allows to write transformations ASR->ASR, which we plan to use for implementing optimizations at this level, before lowering to LLVM or other tools (such as MLIR): Optimizations list (#427) · Issues · lfortran / lfortran · GitLab

  • Our main focus is native code generation. You can follow our progress on compiling this proxy app (Fortran 95): MVP: Roadmap to compile the SNAP project (#313) · Issues · lfortran / lfortran · GitLab

  • We also updated our front page with the latest status: https://lfortran.org/

  • One of our goals is to build a large team of developers and contributors and make it easy for LFortran to be included in other libraries and tools — for that reason we want to make it as easy as possible to contribute to the compiler source code. LFortran currently fully compiles in about 20s on my laptop (it assumes LLVM is already built). We are thinking of (also) making it an fpm package once fpm can compile C++ code. That would make it very easy to install and develop for Fortran users.

The parser, while tedious to initially develop, is the least interesting part of a compiler. Both Flang and LFortran have now a Fortran 2018 parser. Maintaining it is not a big problem. The rest of the compilers are completely different as explained above, so the way I see it, the best way to collaborate are things like:

  • Prototyping and designing new Fortran features for the standard committee

  • Collaborating on the LLVM or MLIR backend that both compilers could use

  • Collaborating / brainstorming how to implement some optimizations

  • Collaborating on extending (if needed) the Fortran language to run well on GPUs and other platforms. Collaborating on how to compile well for those.

  • Collaborating on creating and maintaining a Fortran standard conformance test suite

  • Collaborating on benchmarks

There is nothing wrong with having more than one compiler. On the contrary! We could have just taken the GFortran parser and port it on top of LLVM. But neither Flang nor LFortran chose to do that for various technical and license reasons. Yet GFortran is the most mature and best open source Fortran compiler.

Speaking as a Fortran user, it is very exciting to be able to use multiple compilers that are independent of each other, because that ensures the Fortran code that I write is truly multiplatform — it is not dependent on any one platform or a compiler, and thus “lives on its own”. Finally, competition is extremely good for progress. We are now seeing some new innovative ideas. I believe this is not a zero sum game and all these efforts will benefit the wide Fortran community.

13 Likes