Skip to content

0_RootFS: Build LLVM with flang #10502

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

0_RootFS: Build LLVM with flang #10502

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e6a1e02
0_RootFS: Build LLVM with flang
eschnett Feb 10, 2025
e9ed882
0_RootFS: Build flang only for LLVM >= 18
eschnett Feb 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions 0_RootFS/llvm_common.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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;polly;lld')
build_flang = version >= v"18"
Copy link
Member

@imciner2 imciner2 Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@eschnett eschnett Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@imciner2 imciner2 Feb 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@giordano giordano Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

@imciner2 imciner2 Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

@giordano giordano Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

@imciner2 imciner2 Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@giordano giordano Feb 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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

if build_flang
# flang requires clang and mlir
CMAKE_FLAGS+=(-DLLVM_ENABLE_PROJECTS='clang;flang;lld;mlir;polly')
else
CMAKE_FLAGS+=(-DLLVM_ENABLE_PROJECTS='clang;lld;polly')
end

# Build runtimes
CMAKE_FLAGS+=(-DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libcxxabi;libunwind')
Expand All @@ -144,7 +150,12 @@ function llvm_script(;version = v"8.0.1", llvm_build_type = "Release", kwargs...
CMAKE_FLAGS+=(-DLLVM_BINDINGS_LIST=)

# Turn off docs
CMAKE_FLAGS+=(-DLLVM_INCLUDE_DOCS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF)
if build_flang
# (We need examples to build flang)
CMAKE_FLAGS+=(-DLLVM_INCLUDE_DOCS=OFF -DLLVM_INCLUDE_EXAMPLES=ON)
else
CMAKE_FLAGS+=(-DLLVM_INCLUDE_DOCS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF)
end

# We want a shared library
CMAKE_FLAGS+=(-DLLVM_BUILD_LLVM_DYLIB:BOOL=ON -DLLVM_LINK_LLVM_DYLIB:BOOL=ON)
Expand Down