[offload] Provides a device-side binary linker for diverse range of architectures.

[StevenYangCC]

Provides a device-side binary linker for diverse range of architectures.

[llvmbot]

@llvm/issue-subscribers-offload

Author: None (StevenYangCC)

Provides a device-side binary linker for diverse range of architectures.

[jhuber6]

I don't understand this issue, please be more specific.

[StevenYangCC]

AMDGPU target does not have an object file level linker, their implementation at the bottom of clang-linker-wrapper only has IR level bundler tool.

[jhuber6]

AMDGPU target does not have an object file level linker, their implementation at the bottom of clang-linker-wrapper only has IR level bundler tool.

I'm not sure where this comes from. It's just doing LTO with ld.lld which is a linker. It's true that you can't correctly do object level linking, but you're free to try. It will work so long as whatever function you're calling uses fewer registers than the kernel is launched with. To fix that we'd need the linker to determine resource usage somehow.

[StevenYangCC]

Resource usage can be recorded in ELF file.LTO is doing IR level linking, not binary level linking, we need a binary level device side linker, which can improve module reuse, reduce code size and compile time.

[jhuber6]

We already have metadata for this, look at .AMDGPU.gpr_maximums and others. The problem is using it in the linker, which is a larger issue and will be tracked separately.

[StevenYangCC]

@jhuber6 I'm not talking about AMDGPUs alone, we need to consider that the properties, content, and formats that need to be stored may be different for different architectures. We need to give each one room to play, so it's a much more abstract concept, not a small issue.