choikwa wrote: > > There were some stakeholders who are trying to compile cccl on AMDGPU and > > were looking for a solution in clang. If this short term fix isn't > > desirable, is there any alternative solutions to explore? I understand long > > term solution keeping it as libcall and having libm, but we may be some > > time away from achieving that. > > For now these don't seem to hit any LLVM-IR intrinsics > https://godbolt.org/z/zasTefo53. So you should be able to link them with the > `libm.a` I already have from the [llvm > libc](https://libc.llvm.org/gpu/building.html) I already provide. That might > change in the future however since AFAIK we're going to have every math call > as an intrinsic eventually. > > There's `libm.bc` in the install which you can cram into your compile via > your favorite method. Or just use `-Xoffload-linker -lm` if you're using the > new driver on HIP (I'll make it the default eventually). Alternatively just > make your own `libm.o` that contains the ROCm DL implementation and link that > in. And if absolutely none of that works, make a custom IR lowering pass.
After clang emits builtins as LibCall, it just appears as an external call, and it would be odd for LLVM to reserve and transform certain functions even if it aliases libc builtin function names as -fno-builtin exists and user could've defined their own. I appreciate the suggestions given here and can forward it to the stakeholders. Is there no desirable, acceptable solution in clang-side then? https://github.com/llvm/llvm-project/pull/129347 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
