================ @@ -0,0 +1,21 @@ +#ifndef __CLC_INTEGER_CLC_CLZ_H__ +#define __CLC_INTEGER_CLC_CLZ_H__ + +#if defined(CLC_CLSPV) || defined(CLC_SPIRV) +// clspv and spir-v targets provide their own OpenCL-compatible clz +#define __clc_clz clz ---------------- frasercrmck wrote:
> On the `clspv` side, we only care about functions that we are not capable of > translating with the correct precision using a few Vulkan SPIR-V operators. > > * rhadd: > https://github.com/google/clspv/blob/fea65392ea282dec9a43c3ab86fb63b890f6354e/lib/ReplaceOpenCLBuiltinPass.cpp#L3691 > > * popcount: > https://github.com/google/clspv/blob/fea65392ea282dec9a43c3ab86fb63b890f6354e/lib/SPIRVProducerPass.cpp#L4332 > > > So what `clspv` relies on is math functions that are easy to translate with a > maintainable number of Vulkan operators. Thanks! So for clspv this is (almost) entirely a performance thing, because you can ship a smaller library and have more performant implementations of some of the builtins? What if libclc was able to provide equivalent or better implementations? Would you switch to the libclc implementations? Is the size of the libclc library at all a concern, or is it just a matter of the right codegen? https://github.com/llvm/llvm-project/pull/116786 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
