Fix clashing enqueue kernel wrapper functions

[AnastasiaStulova]

The way wrapper kernels are generated for blocks used in enqueu_kernel doesn't take into account linking of multiple modules that have enqueued blocks with the same name. There are multiple ways how it can be avoided:

• By adding translation unit name into kernel wrapper;
• By hashing.

See original discussion in https://reviews.llvm.org/D115523.

[llvmbot]

@llvm/issue-subscribers-opencl

[yxsamliu]

The translation unit name may not be unique. A program may have files with the same name under different directories, or compile the same file twice with different macro definitions.

[AnastasiaStulova]

Ok, thanks. I think global ctor stubs might be using the full file name with the path although it should be double-checked.

I imagine if different files are used they will be generated into different output files as the input files to the linker must be unique but however, files can be renamed after objects files generation so it's a fair point.

Anyway, I guess we should just check how similar issues are handled in C++ or elsewhere in clang...

[AnastasiaStulova]

Btw I checked the global ctor stubs and they are generated with internal linkage so the uniqueing is guaranteed due to that. There is also special global variable @llvm.global_ctors which I think is used by the ABI to access the stubs somehow?

Anyway the dame approach doesn't seem to be feasible so I guess we should explore the hashing?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[yxsamliu]

I think hashing including the complete file path and compile options should work.