[all-commits] [llvm/llvm-project] 1964c3: [LinkerWrapper] Only import static libraries with ...

[Joseph Huber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1964c334782e7c5961772fbdcdcc0029cba3a7fa
      https://github.com/llvm/llvm-project/commit/1964c334782e7c5961772fbdcdcc0029cba3a7fa
  Author: Joseph Huber <jhuber6 at vols.utk.edu>
  Date:   2023-01-24 (Tue, 24 Jan 2023)

  Changed paths:
    A clang/test/Driver/linker-wrapper-libs.c
    M clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

  Log Message:
  -----------
  [LinkerWrapper] Only import static libraries with needed symbols

Currently, we pull in every single static archive member as long as we
have an offloading architecture that requires it. This goes against the
standard sematnics of static libraries that only pull in symbols that
define currently undefined symbols. In order to support this we roll
some custom symbol resolution logic to check if a static library is
needed. Because of offloading semantics, this requires an extra check
for externally visibile symbols. E.g. if a static member defines a
kernel we should import it.

The main benefit to this is that we can now link against the
`libomptarget.devicertl.a` library unconditionally. This removes the
requirement for users to specify LTO on the link command. This will also
allow us to stop using the `amdgcn` bitcode versions of the libraries.

```
clang foo.c -fopenmp --offload-arch=gfx1030 -foffload-lto -c
clang foo.o -fopenmp --offload-arch=gfx1030 -foffload-lto
```

Reviewed By: tra

Differential Revision: https://reviews.llvm.org/D142484


  Commit: dc60f7aa0435a4e4778cfbf22f4fcb52c97427c0
      https://github.com/llvm/llvm-project/commit/dc60f7aa0435a4e4778cfbf22f4fcb52c97427c0
  Author: Joseph Huber <jhuber6 at vols.utk.edu>
  Date:   2023-01-24 (Tue, 24 Jan 2023)

  Changed paths:
    M clang/lib/Driver/ToolChains/CommonArgs.cpp
    M clang/test/Driver/openmp-offload-gpu.c

  Log Message:
  -----------
  [OpenMP] Unconditionally link the OpenMP device RTL static library

Currently we have two versions of the static library. One is built as
individual bitcode files and linked via `-mlink-builtin-bitcode`. The
other is built as a single static archive `omptarget.devicertl.a` and is
linked via `-lomptarget.devicertl` and handled by the linker wrapper
during LTO. We use the former in the case that we are not performing
LTO, because linking the library late wouldn't allow us to optimize the
runtime library effectively. The support in D142484 allows us to
unconditionally link this library, so it will only be pulled in if
needed. That is, if we linked already via `-mlink-builtin-bitcode` then
we will not pull in the static library even if it's linked on the
command line.

Depends on D142484

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D142486


  Commit: 5d1dc9fa043f8ee239cbc16347025a4f0831e132
      https://github.com/llvm/llvm-project/commit/5d1dc9fa043f8ee239cbc16347025a4f0831e132
  Author: Joseph Huber <jhuber6 at vols.utk.edu>
  Date:   2023-01-24 (Tue, 24 Jan 2023)

  Changed paths:
    M clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
    M clang/test/Driver/amdgpu-openmp-toolchain.c
    M openmp/libomptarget/test/lit.cfg

  Log Message:
  -----------
  [OpenMP] Do not link the bitcode OpenMP runtime when targeting AMDGPU.

The AMDGPU target can only emit LLVM-IR, so we can always rely on LTO to
link the static version of the runtime optimally. Using the static
library only has a few advantages. Namely, it avoids several known bugs
and allows us to optimize out more functions. This is legal since the
changes in D142486 and D142484

Depends on D142486 D142484

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D142491


Compare: https://github.com/llvm/llvm-project/compare/4b88bf5c70c3...5d1dc9fa043f