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
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
