[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