0_RootFS: Build LLVM with flang #10502
Conversation
| @@ -135,7 +135,13 @@ function llvm_script(;version = v"8.0.1", llvm_build_type = "Release", kwargs... | |||
| CMAKE_FLAGS+=(-DCMAKE_BUILD_TYPE=${LLVM_BUILD_TYPE}) | |||
|
|
|||
| # We want a lot of projects | |||
| CMAKE_FLAGS+=(-DLLVM_ENABLE_PROJECTS='clang;flang;lld;mlir;openmp;polly') | |||
| build_flang = version >= v"18" | |||
There was a problem hiding this comment.
IMO we shouldn't be building this flang frontend before LLVM 20. Before then, flang meant the classic flang, and the flang-new frontend was only renamed to flang in LLVM 20. At that point is when upstream LLVM felt it was ready to be used publicly outside of the development effort.
There was a problem hiding this comment.
Building flang for LLVM 18 means building flang-new, which is what we want. I've been using it, and I think it's ready for us to experiment.
I'm not suggesting that we should switch to using flang instead of gfortran right away. That switch-over will need to be well thought-out. I'm saying flang is ready for us to experiment, and without building it we cannot.
There was a problem hiding this comment.
I wasn't suggesting switching from gfortran (flang only pass 80% of the gfortran tests, doesn't have complete support for Fortran 2008+ features, and also doesn't support OpenMP standards above 2.5-ish right now). I was more saying that according to LLVM upstream, they didn't see flang as being suitable for users before LLVM 20 (the rename occurred because they decided it was suitable for wider testing/use now).
Additionally, I think there are still some issues/loose-ends to be worked out upstream with how they handle flang being used as a cross-compiler. For instance, a common theme I have been reading on the LLVM discourse board is that the Fortran runtime is still a bit too closely coupled to the OS/arch that the compiler was built on. There is work to reduce that coupling and make it more suitable for cross-compilation (e.g., https://discourse.llvm.org/t/buildbot-changes-with-llvm-enable-runtimes-flang-rt/83571), but I don't know if that will make it into LLVM 20. So actually, it looks like we will need to do some additional processing to handle the fortran runtime here - which might be a bit cumbersome right now.
There was a problem hiding this comment.
Also, last time I looked at flang (but that was a few years ago) my understanding was that it statically links a runtime (contrary to gfortran which dynamically links libgfortran), but as I said above we don't have the runtime libraries for llvm-based compilers (there should be an issue somewhere opened by Valentin about this).
There was a problem hiding this comment.
Also, last time I looked at flang (but that was a few years ago) my understanding was that it statically links a runtime (contrary to gfortran which dynamically links libgfortran), but as I #10502 (comment) we don't have the runtime libraries for llvm-based compilers (there should be an issue somewhere opened by Valentin about this).
Yes, it looks like it does statically link the runtime (there is a reference to libFortranRuntime.a in https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826). It also looks like some bootstrapping might be needed to actually build the Fortran runtime.
but as I #10502 (comment) we don't have the runtime libraries for llvm-based compilers (there should be an issue somewhere opened by Valentin about this).
Don't we already have the Clang ones? I thought that was in the LLVMCompilerRT package (which apparently hasn't been rebuilt since LLVM 17 though).
There was a problem hiding this comment.
Don't we already have the Clang ones? I thought that was in the LLVMCompilerRT package (which apparently hasn't been rebuilt since LLVM 17 though).
Yes, but as external packages, not as full part of the compiler toolchain (CompilerSupportLibraries_jll is a runtime package only, the GCC toolchains we use come with their own proper runtime libraries used during compilation, and we carefully make sure to use those during build rather than the CSL ones)
There was a problem hiding this comment.
Here is more discussion about cross-compilation not working, this time for the intrinsic modules that are provided with the compiler: https://discourse.llvm.org/t/rfc-building-flangs-builtin-mod-files/84626 (it also discusses the interplay with the openmp target). So I think that upstream really needs to fix all the cross-compilation stuff before we can reliably start packaging flang in a usable state in Ygg.
There was a problem hiding this comment.
(there should be an issue somewhere opened by Valentin about this).
Ah, it wasn't an issue but a PR, that's why I couldn't find it before: #1681
Here is an idea: Flang is these days not half bad at building Fortran code. Instead of combining Clang and GFortran we could try to build projects entirely with LLVM. The first step towards doing so would be to have Flang available in the build system, as enabled by this tentative PR.