[llvm-branch-commits] [flang] [llvm] [Flang] Move runtime library files to FortranRuntime. NFC (PR #110298)

[Michael Kruse via llvm-branch-commits]

Meinersbur wrote:

> This is a gigantic change and I don't understand why it's being made. Why is so much code moving out of flang/ ?

As explained in the summary, this is in preparation of #110217. 

#110217 changes the libFortranRuntime build to use the `LLVM_ENABLE_RUNTIMES` build system, like all the other LLVM runtimes do (compiler-rt, libc, libcxx, libcxxabi, offload, openmp, libunwind). `LLVM_ENABLE_RUNTIMES` was [introduced](https://github.com/llvm/llvm-project/commit/b688c5875d08c586f7b35b8f9da1493ebbf92b45) [to compile](https://discourse.llvm.org/t/rfc-a-vision-for-building-the-runtimes/56751/15) the runtimes for the target triple(s) instead of the host platform. This will be needed to support [cross-compilation with Flang](https://github.com/llvm/llvm-project/issues/102667). Flang is an LLVM project, it should follow LLVM conventions.

The  `LLVM_ENABLE_RUNTIMES` system assumes that each runtime library has a top-level directory in the repository root, so that's where I moved the files to. Moving the common files too was [result of a discussion result in the RFC](https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826/8?u=meinersbur).

While it would be possible to only have a `FortranRuntime/CMakeLists.txt` and leave all the other files in `flang/`, I strongly believe this is a bad idea. It is the norm for LLVM runtimes to have separate sources. Coupling of runtime and compiler also [introduces problems](https://github.com/llvm/llvm-project/pull/110217#discussion_r1793179587) since both are built differently. It should be clear which files (also) belong to the runtime which has different build requirements. For instance, one must use `fortran::common::optional<T>` instead of [`std::optional<T>`](https://github.com/llvm/llvm-project/blob/1be64e5413cbe9cfa89539f70ad02ee1d8945ebe/flang/include/flang/Common/fast-int-set.h#L86) since otherwise the CUDA version fails building. With git being able to track renames, the renaming itself should be the least issues, much less than it would be to accumulate technical debt.

https://github.com/llvm/llvm-project/pull/110298