[Flang] LLVM_ENABLE_RUNTIMES=flang-rt

[Meinersbur]

Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME mechanism.

Motivation:

• Consistency with LLVM's other runtime libraries (compiler-rt, libc, libcxx, openmp offload, ...)
• Allows compiling the runtime for multiple targets at once using the LLVM_RUNTIME_TARGETS configuration options
• Installs the runtime into the compiler's per-target resource directory so it can be automatically found even when cross-compiling

Potential future directions:

• Uses CMake's support for compiling Fortran files, including dependency resolution of Fortran modules
• Improve robustness of compiling libomp.mod when openmp is available
• Remove Flang's dependency from flang-rt's RTNAME function declarations (tblgen?)
• Reduce Flang's build-time dependency from flang-rt's REAL(16) support

See RFC discussion at https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826

Patch series:

• [Flang][NFC] Split common headers to reduce dependencies. #110244
• [Flang][NFC] Split runtime headers in preparation for cross-compilation. #112188
• [Flang][NFC] Move runtime library files to flang-rt. #110298
• [Flang] LLVM_ENABLE_RUNTIMES=flang-rt #110217 (this PR)
• [Flang-RT] Build libflang_rt.so #120213

Patch for lab.llvm.org buildbots:

• Enable Flang-RT for all Flang builders. llvm-zorg#333

[github-actions]

⚠️ Python code formatter, darker found issues in your code. ⚠️

You can test this locally with the following command:

darker --check --diff -r d65a4bcf0d76932e2f6078a7fc7db6ab922fd3fb...02b4731a1b8e02ed600cfb4ba523af836c98e3e8 flang-rt/test/NonGtestUnit/lit.cfg.py flang-rt/test/Unit/lit.cfg.py flang-rt/test/lit.cfg.py flang/test/lit.cfg.py

View the diff from darker here.

--- flang-rt/test/lit.cfg.py	2025-01-02 15:54:24.000000 +0000
+++ flang-rt/test/lit.cfg.py	2025-01-02 18:07:01.586322 +0000
@@ -78,23 +78,21 @@
         "%clang",
         command=FindTool("clang"),
         extra_args=isysroot_flag,
         unresolved="fatal",
     ),
-    ToolSubst("%cc",
-        command=config.cc,
-        extra_args=isysroot_flag,
-        unresolved="fatal"
-    ),
+    ToolSubst("%cc", command=config.cc, extra_args=isysroot_flag, unresolved="fatal"),
 ]
 llvm_config.add_tool_substitutions(tools)
 
 # Let tests find LLVM's standard tools (FileCheck, split-file, not, ...)
 llvm_config.with_environment("PATH", config.llvm_tools_dir, append_path=True)
 
 # Include path for C headers that define Flang's Fortran ABI.
-config.substitutions.append(("%include", os.path.join(config.flang_source_dir, "include")))
+config.substitutions.append(
+    ("%include", os.path.join(config.flang_source_dir, "include"))
+)
 
 # Library path of libflang_rt.a (for lib search path when using non-Flang driver for linking)
 config.substitutions.append(("%libdir", config.flang_rt_output_resource_lib_dir))
 
 # Additional library depedendencies the that Flang driver does not add itself.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[Meinersbur]

I reverted the change that moved flang/module/*.f90 to FortranRuntime/module/*.f90. A lot of Flang tests depend on the *.mod files to be available. Moving the modules to FortranRuntime would either require moving those tests to FortranRuntime as well, or mark them as requiring the module_files (REQUIRES: module_files) and build those before check-flang:

flowchart TB
 subgraph Flang
   direction TB
   flang-new
   check-flang
 end
 subgraph FortranRuntime
   direction TB
   iso_fortran_env_impl("iso_fortran_env_impl.f90")
   lib("libFortranRuntime.a")
   module_files
   check-FortranRuntime
 end

 flang-new --> iso_fortran_env_impl --> lib --> check-FortranRuntime
 flang-new --> module_files --> check-flang
 flang-new --> check-flang
 flang-new --> check-FortranRuntime

Loading

Except the PPC modules, the mod files are not target-specific and hence would not profit from compiling multiple targets from a bootstrap build anyway. However, they are products of the Flang compiler and therefore IMHO logically fits better to the runtime. Also, it would have been nice to make use of CMake's dependency resolution rather than hardcoding Into the CMakeLists.txt. I think it is best to keep that decision out of the current patch.

[vzakhari]

Is this just removed or moved somewhere?

[Meinersbur]

I had expected that I moved those to add_fortranruntime_library but apparently I didn't. I re-added it with the latest push, including some build fixes since it doesn't even work with the trunk version. Even flang-new doesn't compile with the error:

ld.lld: error: undefined symbol: __cudaRegisterLinkedBinary_9067bd07_21_binary_to_decimal_cpp_c17d0b68
>>> referenced by tmpxft_00002a72_00000000-6_binary-to-decimal.cudafe1.cpp
>>>               binary-to-decimal.cpp.o:(__sti____cudaRegisterAll()) in archive lib/libFortranDecimal.a

This is because libFortranDecimal is compiled as CUDA source (but not libFortranCommon) and needed for flang-new. libFortranDecimal for FortranRuntime and Flang should really be compiled independently of each other, as this PR does.

[jhuber6]

Where is this CUDA build actually used? I'm interested in removing it if possible and just building this on top of my other GPU libraries.

[clementval]

We have plan to use it in CUDA Fortran implementation.

[jhuber6]

Is that going to be supported upstream? clang is a CUDA compiler so flang can be as well, but since offloading in flang is already using my driver code (AFAIK) it might be easier to just make it common.

[clementval]

Yes it 's gonna be supported upstream. We are actively working on all the pieces.

[jhuber6]

Alright, any changes I make probably won't impact this since it'll be a separate build. But I would greatly prefer if we stop having many different ways of doing things in the LLVM offloading space.

[ldionne]

I think the global setting of flags is the last comment I have from the perspective of "integration with the runtimes build". I haven't reviewed anything else inside flang-rt/ though.

[jplehr]

I tested this locally and it appears that it requires are more modern CMake version than what was installed (3.22).
According to the LLVM docs (https://releases.llvm.org/12.0.0/docs/GettingStarted.html#id8) currently CMake 3.20 is the minimum required version.

[jhuber6]

Overall I think the patch is fine pending some naming nits, my one concern is the -U__GLIBCXX stuff, because undefining internal vars seems really sketchy. Do we use -nostdlib++ to make sure we don't link the C++ library?

[jeanPerier]

When building the runtime out of tree and running check-flang-rt, I am seeing an error about LLVM header not found

edit: My -DLLVM_DIR was incorrect, never mind.