Open asudarsa opened 4 months ago
This PR should help us to get https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/2500 back by reverting https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/2508
Thanks
The fix of the issue is likely a little bigger than "atomic". The changes covers "atomic" prefix but there are other prefixes in OCLToSPIRVBase::visitCallInst
in OCLToSPIRV.cpp:196 like "convert" or "VLoad" which needs to be handled with care as well. I didn't do deep dive but by quickly glimpsing the code of the function handling that cases it's imaginable to lead Translator again into bogus state by carefully crafted function name. What do you think @MrSidims, @asudarsa?
The fix of the issue is likely a little bigger than "atomic". The changes covers "atomic" prefix but there are other prefixes in
OCLToSPIRVBase::visitCallInst
in OCLToSPIRV.cpp:196 like "convert" or "VLoad" which needs to be handled with care as well. I didn't do deep dive but by quickly glimpsing the code of the function handling that cases it's imaginable to lead Translator again into bogus state by carefully crafted function name. What do you think @MrSidims, @asudarsa?
Hi @bwlodarcz
Thanks much for the feedback. I am now trying several tests trying to manually create the user defined functions with OCL looking names. I will update the PR with my findings.
Sincerely
Several user defined/declared functions were being identified as 'possible' OpenCL builtins as they had prefixes (e.g. atomic_) similar to OpenCL builtin function names. However, they were not present in the OCLSPIRVBuiltinMap. One of the OCLToSPIRV utility functions calls OCLSPIRVBuiltinMap::map function on such user defined functions and this results in a crash. The correct way to do this will be to check if the OCL function name key is present in the map and exit early if not.
This PR does that.
Thanks