Open bashbaug opened 2 months ago
I think this depends on how much the OpenCL C spec defines those builtins. There is the The mapping from an OpenCL C built-in function to the SPIR-V BuiltIn is informational and non-normative.
sentence, but not quite sure if that actually defines anything.
Which means, that those builtins aren't defined as not even the core SPIR-V spec defines them. So I think technically using all of those builtins is strictly speaking undefined behavior to begin with and I was already wondering if something should be done about that.
On the other hand, out of bound accesses are also not defined, so maybe that's a good reason on why to fix it in the translator.
For the following kernel, the
dimidx
value passed toget_global_offset
will be out-of-range for at least some calls regardless of the value ofj
:The OpenCL C spec has defined out-of-range behavior for
get_global_offset
though, so this program is correct:However, when I generate SPIR-V using Clang and the SPIR-V LLVM Translator there are no range checks:
I think there needs to be some sort of
dimidx
check when translatingget_global_offset
, to have the proper out-of-range behavior. These will be removed in most common cases, such as when thedimidx
is an integer literal, but they will probably need to be preserved when the index is unknown like it is in the example above.Since the OpenCL SPIR-V Environment spec requires the GlobalOffset BuiltIn to have three components we probably can use that to simplify the range checks vs. querying the work dimension?
As an aside, we should also clarify in the OpenCL SPIR-V Environment spec what happens to the upper components of the GlobalOffset BuiltIn (and other vector built-ins) when the ND-range dimension is smaller than three.