[llvm-branch-commits] [lld] [llvm] [RFC][AMDGPU][lld] Add object linking support (PR #206787)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> This does not feel like an ELF linker's job, it feels more like your model should require an LTO-ish analysis pass prior to code generation, with the linker kept unaware of this complexity?

This is not a code generation issue, it is assembling the result of codegen from several separate files. Let's say we have two TUs.
```c
// helper.c
void foo() {
  work(); // backend allocates 25 VGPRs for this function in regalloc
}
```
```
// kernel.c
extern void foo();
[[clang::device_kernel]] void kernel() {
  foo(); // runtime needs to allocate 25 VGPRs to call this function correctly
}
```
These are completely separate files, there is no way to share the information required to call `foo()` with the correct number of VGPRs until the link step. The current status quo for AMDGPU is exactly what you described, but it means that AMDGPU can *only* be compiled with monolithic LTO to be correct.
```console
> clang --target=amdgcn-amd-amdhsa -c helper.c -o helper.o
> clang --target=amdgcn-amd-amdhsa -c kernel.c -o kernel.o
> ld.lld -shared kernel.o helper.o -o a.out
```

It is worth noting that NVIDIA's proprietary device linker `nvlink` exists to solve this exact kind of problem. In this scenario, the `helper.o` could come from an entirely different library we don't know about.

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