yxsamliu wrote: > > Would it be feasible to consider switching to the new offloading driver > > mode and really link with the library instead? It may be a conveniently > > isolated use case with little/no existing users that would disrupt. > > I've thought a reasonable amount about a `compiler-rt` for GPUs. Right now > it's a little difficult because of the issue of compatibility. We could do > the traditional "Build the library N times for N architectures", but I'd like > to think of something more intelligent in the future. The use of > `-mlink-builtin-bitcode` handles this by more-or-less forcing correct > attributes. > > What this patch does is a little interesting though, having the clang driver > pick apart archives has always seemed a little weird. We did it in the past > for AMD's old handling of static libraries. There's still a lot of that code > leftover I want to delete. I really need to sit down and allow HIP to work > with the new driver. > > I've been messing around with generic IR a bit, and I think what might work > is LLVM-IR that intentionally leaves off target specific attributes and then > introduce a pass that adds them in if missing before other optimizations are > run. Then we may be able to investigate the use of i-funcs to resolve target > specific branches once the architecture is known (once being linked in). I > think @JonChesterfield was thinking about something to that effect as well.
This patch compiles compiler-rt as a generic bitcode library which is independent of a specific GPU arch. This is like the ROCm device library and is aligned with the trend for gpu libc. Currently I have to use -mlink-bitcode-file to link it since currently the -fno-gpu-rdc mode does not use lld. I believe in the future it should be linked the same way as the gpu libc for the new driver. https://github.com/llvm/llvm-project/pull/71978 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
