soooo.. in OpenCL C builtins like get_global_offset have to return defined values on out of bound accesses, but apparently Intel's driver also gets this wrong. Now I'm considering if I should keep it broken as well, or actually fix it as defined in the spec...
@bashbaug any thoughts on this? Maybe we should add OpenCL CTS tests for this and annoy everybody else with this?
@bashbaug I think this issue should exist with all builtins, but I'm wondering why the SPIRV-Translator is the best place, because I was seeing this with Intel-compute-runtime using OpenCL C as well.
Not saying that it won't make sense to fix it in the translator, but I think it depends on what's meant with "The mapping from an OpenCL C built-in function to the SPIR-V BuiltIn is informational and non-normative." in the env spec.
@karolherbst Our implementation compiles everything through SPIR-V, so the SPIR-V LLVM Translator is involved even when starting from OpenCL C.
Our OpenCL C flow currently goes OpenCL C -> LLVM IR (with calls to get_global_offset) -> SPIR-V (with vector BuiltIns and OpVectorExtractDynamic) -> our GPU compiler, so I think the only place where the fix could go is in the SPIR-V LLVM Translator, when the SPIR-V gets generated from the LLVM IR.