[all-commits] [llvm/llvm-project] db0f75: [OpenMP] Remove 'libomptarget.devicertl.a' fatbina...

[Joseph Huber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: db0f754c5af8e6c96770533520bf8b17fc0dc977
      https://github.com/llvm/llvm-project/commit/db0f754c5af8e6c96770533520bf8b17fc0dc977
  Author: Joseph Huber <huberjn at outlook.com>
  Date:   2025-04-18 (Fri, 18 Apr 2025)

  Changed paths:
    M clang/lib/Driver/ToolChains/Clang.cpp
    M clang/lib/Driver/ToolChains/CommonArgs.cpp
    M clang/test/Driver/openmp-offload-gpu.c
    M offload/DeviceRTL/CMakeLists.txt
    R offload/DeviceRTL/src/exports
    M offload/test/lit.cfg

  Log Message:
  -----------
  [OpenMP] Remove 'libomptarget.devicertl.a' fatbinary and use static library (#126143)

Summary:
Currently, we build a single `libomptarget.devicertl.a` which is a
fatbinary. It is a host object file that contains the embedded archive
files for both the NVIDIA and AMDGPU targets. This was done primarily as
a convenience due to naming conflicts. Now that the clang driver for the
GPU targets can appropriate link via the per-target runtime-dir, we can
just make two separate static libraries and remove the indirection.

This patch creates two new static libraries that get installed into
```
/lib/amdgcn-amd-amdhsa/libomp.a
/lib/nvptx64-nvidia-cuda/libomp.a
```
for AMDGPU and NVPTX respectively. The link job created by the linker
wrapper now simply needs to do `-lomp` and it will search those
directories and link those static libraries. This requires far less
special handling.

This patch is a precursor to changing the build system entirely to be a
runtimes based one. Soon this target will be a standard `add_library`
and done through the GPU runtime targets.

NOTE that this actually does remove an additional optimization step.
Previously we merged all of the files into a single bitcode object and
forcibly internalized some definitions. This, instead, just treats them
like a normal static library. This may possibly affect performance for
some files, but I think it's better overall to use static library
semantics because it allows us to have an 'include-what-you-use'
relationship with the library.

Performance testing will be required. If we really need the merged blob
then we can simply pack that into a new static library.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications