[flang-commits] [clang] [flang] [lld] [llvm] [Flang][NFC] Move runtime library files to flang-rt. (PR #110298)

[Michael Kruse via flang-commits]

Meinersbur wrote:

The intention was to leave the files included in both, runtime and compile, inside the `flang/` subtree. This leaves cross-project include-dependencies only in one direction: "flang-rt" -> "flang/include". This applies header files in "flang/include/Common" and "flang/include/Runtime". Moving them would have just caused for the cross-dependence includes to go the other way around "flang" -> "flang-rt/include" which does not provide a clear benefit and having "flang-rt" and "flang" include header files of each other would make things even more complicated.

This applies to most of the files in "flang/include/Runtime" (including "/CUDA") as well. These forward-declare functions which do not exist in the compiler executable, hence should be used only in the runtime (calling it from the compiler will result in a link error), but they are also used do derive the MLIR argument types when the compiler generates calls to them[^1]. These are the function decorated by `RTNAME` to ensure Fortran calling conventions.

I still moved files to which this does not apply, which cannot and should not be used from the compiler, to flang-rt. This applies e.g. to `descriptor.h` which includes the definition of `class Descriptor`. Its memory layout (and `sizeof(Descriptor)`) is target-dependent, hence must not be used from the compiler since it would errornously assume the ABI of the compiler host, which might be different from the compilation target.

When introduced in 1417633943b77365bda70b1ddddd46a0a3c05300, `allocator.h` did not contain any `RTNAME` declarations, hence the move. This has changed in 4c1dbbe7aaeb1cb3f991e1de9c7d0dd312e565f5 which I seem to have missed, hence I think I will move back the file.

Note that there are still declarations that should not be used from the compiler, and ideally be moved to other header files not in `flang/include`, since not relevant to the compiler, and do not define the runtime API:

 * CUFAllocPinned
 * CUFFreePinned
 * CUFAllocDevice
 * CUFFreeDevice
 * CUFAllocManaged
 * CUFFreeManaged
 * CUDA_REPORT_IF_ERROR (now in `common.h`)

[^1]: This is a bad idea anyway since C types correspond to different ABI types depending on the compilation target. E.g. `size_t` can be `unsigned int`, `unsigned long`, or `unsigned long long`. The type resolution to MLIR types is done using templates, i.g. on some targets (i.e.: 32-bit platforms) the template specilization `template<> class <size_t>` will be ambiguous with `template<> class <unsigned int>`,  and error-out the compiler. Will eventually need to be replaced with a table-gen approach, like libc does.

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