[clang] [compiler-rt] [llvm] [HIP] support 128 bit int division (PR #71978)

[Joseph Huber via cfe-commits]

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