[clang] [llvm] [LinkerWrapper] Support relocatable linking for offloading (PR #80066)

Joseph Huber via cfe-commits cfe-commits at lists.llvm.org
Wed Jan 31 12:09:33 PST 2024


jhuber6 wrote:

> > the idea is that it would be the desired effect if someone went out of their way to do this GPU subset linking thing.
> 
> That would only be true when someone owns the whole build. That will not be the case in practice. A large enough project is usually a bunch of libraries created by different teams and vendors. They may or may not be built together and how a particular library is built is often controlled by its owner and may not be visible to the end user. The owners may consider switching to device linking to be benign or irrelevant to the end users, but it will be observable by those upstream users.

To me, if the person owning the library chooses to do this in their build system it would speak to an intentional decision not to leak the GPU parts of their code. with shipped via a static library. More or less, this option would give people a way to ship static libraries with the same GPU / Offloading semantics as a shared library.

Another advantage of this option is that it allows someone to build an application with GPU offloading using `clang` and then ship it as a static library that can be linked with GCC or some other compiler so long as the user has the appropriate runtime.

> Being aware of the quirks introduced by device linking will be required for the owners of those libraries. You do know how it all works under the hood. Pretty much nobody else on the planet does. :-)
>

Very true, I need to remind myself that I'm probably the only one who knows how this thing works in detail.

> Anyways. I think we're in agreement that we do need to document possible implications. clang-linker-wrapper docs would do.

Will do.

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


More information about the cfe-commits mailing list