I lead the development of OpenMP for AMD GPUs and work with others at AMD who support OpenMP on AMD CPUs. On behalf of our development teams, we greatly appreciate your efforts to move the development of flang into a subproject in the llvm-project repository and to integrate this development effort into the overall LLVM development community.
Like most commercial companies, we have certain procedures (some legal) to participate in open source projects. Since AMD has already engaged in LLVM development, adding flang as an LLVM subproject makes it much easier to participate in the development of flang. I look forward to my team getting more involved in the development of flang now that it is part of LLVM.
I would respectfully disagree with “There’s nothing llvm about it”. Flang uses the clang offloading architecture used by cuda, hip, and openmp-target. And the runtime will use both libomp and libomptarget runtimes found in the llvm project openmp. While flang frontend may not immediately use clang -cc1 parsing and codegen, the upstream clang driver already supports a flang toolchain. See clang/lib/Driver/Types.cpp and clang/lib/Driver/ToolChains/Flang.cpp.
I think it is better for flang to join LLVM sooner than later. This will help flang developers better adopt llvm development practices. For example, an earlier variant of flang written in c, generated LLVM-IR without using llvm::IRBuilder. This is because the origin of that source was from a non-LLVM project. This architecture was rejected partly because it was not llvm enough. This lead to the creation of the f18 C++ project which will use llvm::IRbuilder. F18 is the flang that I expect and hope to land in monorepo next Monday.
I am also AMD’s representative to the OpenMP Architecture Review Board. Adding flang is an important step to completely cover the OpenMP specification for c, C++, and FORTRAN in LLVM.
I agree, flang has a long way to go. But I believe there is enough critical mass with flang to join the LLVM development now.
Thanks to everyone for the feedback — both concerns and support.
Let me add a perspective as someone who has been responsible for helping to start part of the initial push and finding funding for a portion of the Flang/f18 efforts to date. From the outset our mindset was to get Flang to a point where it was worthy of becoming a part of the LLVM community. So making Flang a successful part of the LLVM community has been a major factor in our viewpoint from the outset. That may not be reflected in the nature of the code base as some might prefer to see it today but I personally view the monorepo landing as the point in time where Flang actually becomes the community’s project.
For exactly the same reasons Greg mentions, having Flang in the monorepo will help many of us avoid hassles to be able to contribute to the code base. Something that makes the formation of a supporting subset of the community extremely difficult. I strongly believe the longer Flang stays separated from the monorepo the harder it will become to transition — simply because the odds that the steps taken to meet target deliverables and features won’t necessarily be addressed as part of the community’s discussions (I think this thread has in part shown that we’re already here today and need to move beyond it sooner rather than later). The steps of landing Flang into the monorepo should simply be viewed as the very first steps and should in no way be considered to be the final ones.
(As a note, you didn’t reply to the thread so I didn’t see this until now.)
As I said in my previous thread: “You don’t use a single llvm header anywhere” that’s a pretty low bar for “looks like an llvm project” - and nothing has changed in the 3 weeks since I sent my earlier message. “We plan on” isn’t a very compelling argument for “looks like llvm”.
As far as the current use in the clang driver: Honestly I don’t think you should be using the clang driver and had I seen I probably wouldn’t have accepted those patches either. I think it would be better off to turn parts of the driver you might need into a separable library rather than include fortran support into a “c based languages” driver and will probably try to dig up that patch set and comment.
To be clear: I support the idea of a fortran compiler in llvm and appreciate that you want to do it right. I would like to see a plan of attack before we talk about imminently putting things in as relying on the community to adopt llvm development practices and libraries seems to put a lot of weight in the community rather than on the project that wants to move in.
I disagree on this part quite a bit. First of all, there is quite a bit
code in the wild that expects at least basic support in the "gcc"
frontend for handling Fortran. Additionally, there is a very significant
overlap in the platform handling and little Fortran specific logic
assuming that we don't end up with hundreds of tuning options in the
frontend. That was the biggest concern for me with the first flang
patches to the clang driver: insane amount of fine-tuning flags and
magic number mappings.
This is an absolutely fair response, but I think the answer there is making a lot of the clang driver a library and not having clang support fortran compilation.
I disagree on this part quite a bit. First of all, there is quite a bit
code in the wild that expects at least basic support in the "gcc"
frontend for handling Fortran. Additionally, there is a very significant
overlap in the platform handling and little Fortran specific logic
assuming that we don't end up with hundreds of tuning options in the
frontend. That was the biggest concern for me with the first flang
patches to the clang driver: insane amount of fine-tuning flags and
magic number mappings.
This is an absolutely fair response, but I think the answer there is making a lot of the clang driver a library and not having clang support fortran compilation.
First, I completely agree that we should have a "frontend driver" library in LLVM. There are lots of frontends that need to know how to call the linker and make a executable program, shared library, etc., and we should have some reusable infrastructure for that.
In this case, however, Fortran is somewhat of a special case for historical reasons. To emulate gcc, our driver needs to know how to invoke a Fortran compiler. Considering that, especially considering our long-standing support for being a driver for gfortran for this reason, and the other similarities in the compilation models, having this in Clang seems reasonable to me. The reality is that, in terms of toolchains, the triple of C/C++/Fortran go together for a significant set of programming environments, and there has long been a coupling at this driver level (at large).
> > As far as the current use in the clang driver: Honestly I don't think you
> > should be using the clang driver and had I seen I probably wouldn't have
> > accepted those patches either. I think it would be better off to turn parts
> > of the driver you might need into a separable library rather than include
> > fortran support into a "c based languages" driver and will probably try to
> > dig up that patch set and comment.
>
> I disagree on this part quite a bit. First of all, there is quite a bit
> code in the wild that expects at least basic support in the "gcc"
> frontend for handling Fortran. Additionally, there is a very significant
> overlap in the platform handling and little Fortran specific logic
> assuming that we don't end up with hundreds of tuning options in the
> frontend. That was the biggest concern for me with the first flang
> patches to the clang driver: insane amount of fine-tuning flags and
> magic number mappings.
>
>
> This is an absolutely fair response, but I think the answer there is making a lot of the clang driver a library and not having clang support fortran compilation.
>
>
First, I completely agree that we should have a "frontend driver"
library in LLVM. There are lots of frontends that need to know how to
call the linker and make a executable program, shared library, etc.,
and we should have some reusable infrastructure for that.
FWIW, that was one of the reasons why we now have `llvm/lib/Frontend`
and the corresponding libraries for the subdirectories.
In addition to frontends, the linker will probably need to know about
various bits, e.g., how to find nvcc, if we have fat-binary/offloading
support in the linker.