[llvm-branch-commits] [llvm] [Offload] Add `olLinkProgram` (PR #148648)

Joseph Huber via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Tue Jul 15 06:17:32 PDT 2025


jhuber6 wrote:

> @jhuber6 I'm looking at implementing a version of [urProgramLink](https://oneapi-src.github.io/unified-runtime/core/api.html#urprogramlink) for liboffload, which is used by SYCL.
> 
> More generally though, linking is very backend dependant, and liboffload already has logic for invoking the appropriate tool (lld/ptxas/etc.). I think it's worthwhile exposing this interface to offload consumers so they don't have to fiddle around with implementing their own wrappers around the linker. In theory, liboffload could even set optimisation flags that it knows it can consume as well. Implementers can also dynamically compute what kernels they want to use at runtime and link those into a single module rather than unconditionally loading a huge image to the device.
> 
> If users do want to compile offline though, why not just have the hypothetical `offload-lld` be a simple wrapper around `olLinkProgram` and save having to implement linking in two places?

My gut reaction is that if people need a compiler they could just invoke `clang` themselves. That's basically what the linker wrapper does, it just invokes `clang --target=amdgcn-amd-amdhsa` or whatever and expects a functioning executable to come out from the input. It just seems a little out of scope to be compiling and linking entire applications beyond simple JIT.

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


More information about the llvm-branch-commits mailing list