[libclc] [libclc] Move __clc_ldexp to CLC library (PR #126078)

[Fraser Cormack via cfe-commits]

frasercrmck wrote:

> > I'll go add that builtin and come back to this - thanks.
> > What do you think about libclc making use of weak linkage in principle?
> 
> Weak should be handled properly by the targets, the one downside is that it prevents optimization within a TU because the symbol's initializer could change, but LTO / noRDC-mode compilation makes that irrelevant. Also, even though NVPTX is an ELF platform it doesn't handle `extern weak` properly (It's supposed to be defined to zero if not defined). I think using weak is fine in the sense that it's well supported by LLVM and the GPU targets, but I don't know OpenCL's perspective.

Thanks for the information. I don't think we rely on intra-TU optimizations too heavily as we generally build each builtin function in isolation. As for what OpenCL thinks, I suspect it's left loose in the specification. It "works" as far as clang's concerned. The 'weak' CLC functions will generally always be inlined into a regular non-weak user-facing builtin at the interface layer.

> Also completely unrelated question since you seem to know about `libclc`. It seems to require `clang` to be compiled, but can't be built through the runtimes interface. Do you know how difficult it would be to make that work? I'm somewhat interested in having it work through the compilation steps I use for other GPU libraries like compiler-rt, libc, libcxx, libcxxabi, and soon openmp.
> 
> Basically it would look like this.
> 
> ```
> -DLLVM_RUNTIME_TARGETS=amdgcn-amd-amdhsa
> -DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES='libc;libclc
> ```
> 
> That would create a separate CMake invocation that would run with the https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_TARGET.html set to `amdgcn-amd-amdhsa` (or whatever triple you prefer.) So you'd be doing one job with only the AMD triple set. I don't know where the libraries get stored, but by default they'd go in `lib/amdgcn-amd-amdhsa` which `clang` knows where to find.

I hadn't heard of this mechanism, thanks for pointing it out. It makes complete sense to me to allow this. I will take a look at it - without knowing how it works it's hard to say whether it'll be a lot of work.

Regarding triples, libclc doesn't currently have a `amdgcn-amd-amdhsa` target, per se. It's got `amdgcn--` or `amdgcn--amdhsa`. Again I don't know how the runtimes triples work and how strict the triple matching would be or if libclc would have to massage triples into its own internal set. If a triple isn't found, like `x86_64-unknown-linux-gnu` is it silently ignored, warned, errored?

As for where the libraries are placed, it's currently not at all integrated with clang. They're currently in, e.g., `build/tools/libclc/amdgcn--amdhsa.bc`. There's no in-tree use of libclc, which I'd like to change. I know that @arsenm has been proposing that the libraries are made known to clang but I've not had the chance to look into that either.

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