yaxunl added a comment. In D59316#1431276 <https://reviews.llvm.org/D59316#1431276>, @arsenm wrote:
> In D59316#1431253 <https://reviews.llvm.org/D59316#1431253>, @yaxunl wrote: > > > In D59316#1431238 <https://reviews.llvm.org/D59316#1431238>, @arsenm wrote: > > > > > In D59316#1429580 <https://reviews.llvm.org/D59316#1429580>, @yaxunl > > > wrote: > > > > > > > Here we are looking at the code which emulates a "linker" for HIP > > > > toolchain. The offloading action builder requests the offloading > > > > toolchain have a linker, but amdgpu does not have a real linker (ISA > > > > level linker), so we have to emulate that. If we have an ISA level > > > > linker we can get rid of all these stuff, but I don't think that will > > > > happen in short time. > > > > > > > > > This isn't really true. We do run lld to link the final executable. It > > > also doesn't change that opt and llc should never be involved in the > > > process > > > > > > Can lld do ISA level linking? That is, one device function in one object > > file calls another device function in a different object file, and we let > > lld link them together? > > > We can't link multiple objects, but we do need to link the single object with > lld. The relocations even for functions in the same module are 0 until lld > fixes them up. Do we have execution tests for function calls using HIP? Since > it looks like lld isn't getting used here, I suspect they aren't workingh In D59316#1431276 <https://reviews.llvm.org/D59316#1431276>, @arsenm wrote: > In D59316#1431253 <https://reviews.llvm.org/D59316#1431253>, @yaxunl wrote: > > > In D59316#1431238 <https://reviews.llvm.org/D59316#1431238>, @arsenm wrote: > > > > > In D59316#1429580 <https://reviews.llvm.org/D59316#1429580>, @yaxunl > > > wrote: > > > > > > > Here we are looking at the code which emulates a "linker" for HIP > > > > toolchain. The offloading action builder requests the offloading > > > > toolchain have a linker, but amdgpu does not have a real linker (ISA > > > > level linker), so we have to emulate that. If we have an ISA level > > > > linker we can get rid of all these stuff, but I don't think that will > > > > happen in short time. > > > > > > > > > This isn't really true. We do run lld to link the final executable. It > > > also doesn't change that opt and llc should never be involved in the > > > process > > > > > > Can lld do ISA level linking? That is, one device function in one object > > file calls another device function in a different object file, and we let > > lld link them together? > > > We can't link multiple objects, but we do need to link the single object with > lld. The relocations even for functions in the same module are 0 until lld > fixes them up. Do we have execution tests for function calls using HIP? Since > it looks like lld isn't getting used here, I suspect they aren't working hip-clang has been used for compiling and running real ML applications without issue. We do have lld step, see line 281. We do need to link different objects for this LinkerJob. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59316/new/ https://reviews.llvm.org/D59316 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
