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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to