Anastasia added a comment. In D115523#3240870 <https://reviews.llvm.org/D115523#3240870>, @yaxunl wrote:
> In D115523#3237857 <https://reviews.llvm.org/D115523#3237857>, @Anastasia > wrote: > >> In D115523#3237410 <https://reviews.llvm.org/D115523#3237410>, @yaxunl wrote: >> >>> It is possible that block kernels are defined and invoked in static >>> functions, therefore two block kernels in different TU's may have the same >>> name. Making such kernels external may cause duplicate symbols. >> >> Potentially we should append the name of the translation unit to all kernel >> wrapper names for the enqueued blocks to resolve this? For example, global >> constructors stubs are using such a similar naming scheme taken from the >> translation unit. >> >> But the kernel function in OpenCL has to be globally visible and many tools >> have been built with this assumption. Additionally, some toolchains might >> require the enqueued kernels to be globally visible as well in order to >> access them as an execution entry point. > > If we have to externalize such block kernels whose names are derived from > variables with internal linkage, we may need a way to make the block kernel > names unique. > > One approach would be use MD5 hash of the file path and compile options, > similar to > https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/Driver.cpp#L2623 Ok, however it might be enough to do what C++ handling does with global ctors. Should we file a bug for this for now? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115523/new/ https://reviews.llvm.org/D115523 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
