jhuber6 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. 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
