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