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