[PATCH] D152882: [LinkerWrapper] Support device binaries in multiple link jobs

Joseph Huber via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 15 09:01:57 PDT 2023


jhuber6 added inline comments.


================
Comment at: clang/test/Driver/linker-wrapper.c:48
+// AMDGPU-LINK-ID: clang{{.*}} -o {{.*}}.img --target=amdgcn-amd-amdhsa -mcpu=gfx90a -O2 -Wl,--no-undefined {{.*}}.o {{.*}}.o
+
 // RUN: clang-offload-packager -o %t.out \
----------------
yaxunl wrote:
> can we put some variables in the input bitcode so that we can check the linked bitcode?
> 
> I would expect there will be only one linked bitcode for gfx90a:xnack+ and it contains both variables.
> 
> I don't think it is a good idea to let the final object embed bitcode for both gfx90a:xnack+ and gfx90a since that will result in an invalid container. Therefore I think we should only do linking with target ID's from the first container.
I can make a static library that's `gfx90a`, that covers the main case where we still link in the OpenMP runtime library that's compiled with `90a` if the user uses `90a:xnack+`. I'd need to place a random external variable to force it to extract however.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152882/new/

https://reviews.llvm.org/D152882



More information about the cfe-commits mailing list