[PATCH] D115523: [OpenCL] Set external linkage for block enqueue kernels

Anastasia Stulova via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jan 24 09:07:13 PST 2022


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



More information about the cfe-commits mailing list