[clang] [AMDGPU] add function attrbute amdgpu-lib-fun (PR #74737)

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> I was thinking of implementing libm/libc for nvptx, which would produce an IR library . We'll still need to keep the functions around if they are not used explicitly, because we may need them to fulfill libcalls later in the compilation pipeline. Sort of a libdevice replacement which can be used for libcall materialization.
> 
> But you're right, with RDC object files used for offloading it's probably not necessary.

That's one problem I'm unsure of how to solve currently. Right now when doing LTO, there's a list of "libfuncs" that backends can emit. If the function is one of these we can't interalize / optimize out the symbol. I was attempting to relax this in https://reviews.llvm.org/D154364 at some point, because ideally we don't want to do this if the backend doesn't use them, but we don't have that logic right now.

Right now, the issue is how to handle divergence for different targets. So, for `libc/libm` we just build the same library N times for each architecture. This allows us to use things like `__CUDA_ARCH__` and `__has_builtin` as normal because it has a unique file for each architecture. However, I really don't think that N files is a scalable solution and would like to be able to create generic IR for a single file. Basically I'd like to have something like `libdevice.bc` where it's just one file. The problem is that we don't have a good, robust way to express this. Nvidia uses their reflection you're well aware of, and AMD uses external globals which need to be resolved by some link job.

One reason I'd like this is because I'd really like to be able to provide my `crt1.o` and `libc.a` as exported targets such that someone can do `clang++ --target=amdgcn-amd-amdhsa -mcpu=native foo.cpp crt1.o -lc` and have it work correctly. Right now fishing out the correct file requires linker wrapper magic. 

https://github.com/llvm/llvm-project/pull/74737