[all-commits] [llvm/llvm-project] 5c8405: [LinkerWrapper] Support relocatable linking for of...

[Joseph Huber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5c84054223102b00cc0dd343a4023e3c6cba42b2
      https://github.com/llvm/llvm-project/commit/5c84054223102b00cc0dd343a4023e3c6cba42b2
  Author: Joseph Huber <huberjn at outlook.com>
  Date:   2024-02-07 (Wed, 07 Feb 2024)

  Changed paths:
    M clang/docs/ClangLinkerWrapper.rst
    M clang/docs/OffloadingDesign.rst
    M clang/test/Driver/linker-wrapper-image.c
    M clang/test/Driver/linker-wrapper.c
    M clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
    M clang/tools/clang-linker-wrapper/LinkerWrapperOpts.td
    M llvm/include/llvm/Frontend/Offloading/OffloadWrapper.h
    M llvm/lib/Frontend/Offloading/OffloadWrapper.cpp
    M llvm/lib/Object/OffloadBinary.cpp

  Log Message:
  -----------
  [LinkerWrapper] Support relocatable linking for offloading (#80066)

Summary:
The standard GPU compilation process embeds each intermediate object
file into the host file at the `.llvm.offloading` section so it can be
linked later. We also use a special section called something like
`omp_offloading_entries` to store all the globals that need to be
registered by the runtime. The linker-wrapper's job is to link the
embedded device code stored at this section and then emit code to
register the linked image and the kernels and globals in the offloading
entry section.

One downside to RDC linking is that it can become quite big for very
large projects that wish to make use of static linking. This patch
changes the support for relocatable linking via `-r` to support a kind
of "partial" RDC compilation for offloading languages.

This primarily requires manually editing the embedded data in the
output object file for the relocatable link. We need to rename the
output section to make it distinct from the input sections that will be
merged. We then delete the old embedded object code so it won't be
linked further. We then need to rename the old offloading section so
that it is private to the module. A runtime solution could also be done
to defer entries that don't belong to the given GPU executable, but this
is easier. Note that this does not work with COFF linking, only the ELF
method for handling offloading entries, that could be made to work
similarly.

Given this support, the following compilation path should produce two
distinct images for OpenMP offloading.
```
$ clang foo.c -fopenmp --offload-arch=native -c
$ clang foo.c -lomptarget.devicertl --offload-link -r -o merged.o
$ clang main.c merged.o -fopenmp --offload-arch=native
$ ./a.out
```

Or similarly for HIP to effectively perform non-RDC mode compilation for
a subset of files.

```
$ clang -x hip foo.c --offload-arch=native --offload-new-driver -fgpu-rdc -c
$ clang -x hip foo.c -lomptarget.devicertl --offload-link -r -o merged.o
$ clang -x hip main.c merged.o --offload-arch=native --offload-new-driver -fgpu-rdc
$ ./a.out
```

One question is whether or not this should be the default behavior of
`-r` when run through the linker-wrapper or a special option. Standard
`-r` behavior is still possible if used without invoking the
linker-wrapper and it guaranteed to be correct.