[llvm-dev] Flang landing in the monorepo - next Monday!
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 15 02:13:52 PST 2020
On Wed, 15 Jan 2020 at 09:11, Richard Barton <Richard.Barton at arm.com> wrote:
> I don’t think we can be sure of a timeline for completion of this work. In reality adding this part of the frontend will likely be an ongoing effort over the next months, perhaps years and it will likely be a work in progress by the time of the LLVM11 branch. We can at least commit to starting this effort soon, lead by Nvidia. If we don't merge to monorepo shortly then the work will start on the F18 github project. Arm engineers will be reviewing, but we think the benefit of doing this development in the monorepo is that other interested parties can join in from the MLIR and LLVM projects. We'd ask that we merge to the monorepo before the review starts.
I wouldn't like to forcefuly tie in LLVM API support in Flang with
MLIR-LLVM dialect support, as the latter is good, but not necessarily
Ideally, it would be best to tackle them at the same time (no point in
doing two complex projects if the latter replaces the former), but I'm
not sure LLVM will be ready to accept MLIR as an input IR off the bat.
I have no opinion on either, I just want to make sure we're taking an
informed decision here.
Doing both at the same time may push the the work past the 11 branch,
which then will mean 10, 11 and 12 will have three different stages
with their own incompatibilities.
This sucks really bad for users.
> The previous flang (to be absolutely clear - I mean this one: https://github.com/flang-compiler/flang) did not use the LLVM API as you say, instead writing a .ll file and calling clang on that file. F18 will certainly use LLVM APIs to generate IR directly but that code has not made it to the master F18 branch today. It is not true to say that F18 has inherited this flaw from its predecessor.
I didn't mean code inheritance, just design inheritance.
My point was that there were clear feedback from last time, mainly:
use LLVM API, use LLVM testing infrastructure, use LLVM coding
However, despite being (I was told) a completely new project, those
major flaws still exists and they are, again, getting in the way of
It feels as if the message wasn't clear enough.
> To clarify, F18 code is compatible to C++17 so it is currently ahead of the standard used by the rest of the LLVM project. That is an issue by itself that needs managing, but a different problem from the one you describe here.
I stand corrected, thanks! :)
More information about the llvm-dev