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

[Yaxun Liu via cfe-commits]

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