[flang-rt] Update test_flang in CI to use flang-rt as one of the projects.

[DanielCChen]

The CI test_flang seems not being updated since flang-rt is separated from the flang build.
This PR is to update test_flang to put flang-rt as one of the projects when testing flang, so it uses bootstrap build instead of part of the flang build, which we are moving away from. It is also consistent with the buildbots.
I am not familiar with the CI configuration, so this PR serves as an initiation for the update.

[github-actions]

✅ With the latest revision this PR passed the Python code formatter.

[DanielCChen]

The PR may have dependency on PR #134362 as it will need the driver change to get the full path to libflang_rt.runtime.a.

[boomanaiden154]

so it uses bootstrap build instead of part of the flang build

So adding flang-rt to LLVM_ENABLE_PROJECTS will cause it to use a just-built clang/flang (although a cursory glance seems to show there is no Fortran code in flang-rt?) for compilation? That is completely different from how all the other runtimes work (they use the host compiler for LLVM_ENABLE_PROJECTS and will use a just built compiler when specified in LLVM_ENABLE_RUNTIMES).

[DanielCChen]

so it uses bootstrap build instead of part of the flang build

So adding flang-rt to LLVM_ENABLE_PROJECTS will cause it to use a just-built clang/flang (although a cursory glance seems to show there is no Fortran code in flang-rt?) for compilation? That is completely different from how all the other runtimes work (they use the host compiler for LLVM_ENABLE_PROJECTS and will use a just built compiler when specified in LLVM_ENABLE_RUNTIMES).

Thanks for the comment!

For building flang, if you only do -DLLVM_ENABLE_PROJECTS=clang;mlir;flang, it builds flang as well as flang-rt together.
If you add -DLLVM_ENABLE_RUNTIMES=flang-rt, it will separate the build of flang-rt and publish it to resource-dir.

The intention of this PR is to prevent building flang-rt as part of the flang build. Rather, build it with LLVM_ENABLE_RUNTIMES. This is how the buildbot is doing.

As the flang-rt build is similar to compiler-rt, I mimicked compiler-rt in this PR. I am not sure if I missed anything or overdid anything.

[boomanaiden154]

The intention of this PR is to prevent building flang-rt as part of the flang build. Rather, build it with LLVM_ENABLE_RUNTIMES. This is how the buildbot is doing.

As the flang-rt build is similar to compiler-rt, I mimicked compiler-rt in this PR. I am not sure if I missed anything or overdid anything.

That's not how the premerge build system is setup. The list of projects computed here gets sent directly to monolithic-linux.sh and monolithic-windows.sh which you can see in generate-buildkite-pipeline-premerge and .github/workflows/premerge.yaml. Those scripts just shove everything into LLVM_ENABLE_PROJECTS. We need to migrate compiler-rt and libc off of the projects build, but haven't done it yet as I need to dig into the host toolchain support story there.

What's the compiler support story like for flang-rt? Is it fine to build it with a recent clang or does it need to be built with the just-built compiler? Is it going to have fortran source eventually (or does it already)?

[DanielCChen]

The intention of this PR is to prevent building flang-rt as part of the flang build. Rather, build it with LLVM_ENABLE_RUNTIMES. This is how the buildbot is doing.

As the flang-rt build is similar to compiler-rt, I mimicked compiler-rt in this PR. I am not sure if I missed anything or overdid anything.

That's not how the premerge build system is setup. The list of projects computed here gets sent directly to monolithic-linux.sh and monolithic-windows.sh which you can see in generate-buildkite-pipeline-premerge and .github/workflows/premerge.yaml. Those scripts just shove everything into LLVM_ENABLE_PROJECTS. We need to migrate compiler-rt and libc off of the projects build, but haven't done it yet as I need to dig into the host toolchain support story there.

What's the compiler support story like for flang-rt? Is it fine to build it with a recent clang or does it need to be built with the just-built compiler? Is it going to have fortran source eventually (or does it already)?

I see.
Right, both compiler-rt and flang-rt should not be in LLVM_ENABLE_PROJECTS in the premerge build.
In the buildbots, they are in LLVM_ENABLE_RUNTIMES for the in-tree build.

If I have LLVM_ENABLE_PROJECTS=clang, compiler-rt is not built. However, if I have LLVM_ENABLE_PROJECTS=flang, flang-rt is built as part of the flang project.

I see the premerge scripts only use LLVM_ENABLE_PROJECTS but not LLVM_ENABLE_RUNTIMES. It always build runtimes as a standalone build.

I start to think the proper fix probably should be that we stop building flang-rt as part of the flang project in cmake, and uses standalone runtime premerge build when testing flang or flang-rt changes.

[boomanaiden154]

I start to think the proper fix probably should be that we stop building flang-rt as part of the flang project in cmake, and uses standalone runtime premerge build when testing flang or flang-rt changes.

That sounds about right. We need to rework the runtimes build for premerge anyways which has been on my TODO list for a while and something I hope to get too soon.

What are the compiler requirements for flang-rt? From what I can tell it is entirely c++ currently. Does it need ToT clang/flang?

[DanielCChen]

I start to think the proper fix probably should be that we stop building flang-rt as part of the flang project in cmake, and uses standalone runtime premerge build when testing flang or flang-rt changes.

That sounds about right. We need to rework the runtimes build for premerge anyways which has been on my TODO list for a while and something I hope to get too soon.

What are the compiler requirements for flang-rt? From what I can tell it is entirely c++ currently. Does it need ToT clang/flang?

There is some description of how to build it. https://github.com/llvm/llvm-project/tree/main/flang-rt

I copied some here. It doesn't need bootstrap C/C++ compilers, but it needs the Fortran compiler flang built from the same commit.

The compiler to be used can be controlled using CMake's standard mechanisms such as CMAKE_CXX_COMPILER, CMAKE_CXX_COMPILER, and CMAKE_Fortran_COMPILER. CMAKE_Fortran_COMPILER must be flang built from the same Git commit as Flang-RT to ensure they are using the same ABI. The C and C++ compiler can be any compiler supporting the same ABI.

In addition to the compiler, the build must be able to find LLVM development tools such as lit and FileCheck that are not found in an LLVM's install directory. Use CMAKE_BINARY_DIR to point to directory where LLVM has been built. A simple build configuration might look like the following:

cmake -S <path-to-llvm-project-source>/runtimes              \
  -GNinja                                                    \
  -DLLVM_BINARY_DIR=<path-to-llvm-builddir>                  \
  -DCMAKE_Fortran_COMPILER=<path-to-llvm-builddir>/bin/flang \
  -DCMAKE_Fortran_COMPILER_WORKS=yes                         \
  -DLLVM_ENABLE_RUNTIMES=flang-rt                            \
  ...

There is a Fortran intrinsic module in flang-rt that requires Fortran compiler.

So for the part of the script that specifies LLVM_ENABLE_PROJECTS, are you planning to add LLVM_ENABLE_RUNTIMES? That could be used to build and test compiler-rt and flang-rt as alternative to the standalone build, which could be more straight forward for the premerge building and testing purpose as the driver is already searching the path to the libraries of that build.

[boomanaiden154]

So for the part of the script that specifies LLVM_ENABLE_PROJECTS, are you planning to add LLVM_ENABLE_RUNTIMES?

Maybe. I need to figure out a good way to enable good compilation caching when possible while keeping things simple.

That could be used to build and test compiler-rt and flang-rt as alternative to the standalone build

We would not use the standalone build. We would be using the runtimes build either way. If we did the build separately we would just be using the runtimes build:

cmake -GNinja -DCMAKE_BUILD_TYPE=Release -D... ../runtimes

That should probably be a configuration flang-rt should support if it does not already.

[DanielCChen]

cmake -GNinja -DCMAKE_BUILD_TYPE=Release -D... ../runtimes

That should probably be a configuration flang-rt should support if it does not already.

Yes. flang-rt already supports this configuration. This is actually what we call "standalone" flang-rt build, as it doesn't need to build flang.

However, in order to build flang-rt with this configuration, it will need a flang compiler that is built off the same github commit. This seems to me that the premerge build will need to build flang anyway.

Instead of doing the above, we could modify monolithic-linux.sh to do what we call "bootstrap" build as:

cmake -S "${MONOREPO_ROOT}"/llvm -B "${BUILD_DIR}" \
      -D LLVM_ENABLE_PROJECTS="${projects}" \
      -DLLVM_ENABLE_RUNTIMES="flang-rt" \
      ...

For both flang and flang-rt PRs.

This configuration is what the buildbots are using too.

The difference is the addition of -DLLVM_ENABLE_RUNTIMES="flang-rt" \, which will put the flang-rt to the resource-dir that the driver is searching for. Without it, the flang-rt is still built at the moment as part of project flang but is put to the DefaultLibPath that driver is no longer searching as we will move away from it and disable building flang-rt as part of flang in the near future.