Core SPIR-V feature `SubgroupSize` is translated to non-core attribute `intel_reqd_sub_group_size`

[AdamBrouwersHarries]

It appears that the SubgroupSize execution mode is being translated to the attribute intel_reqd_sub_group_size. This is surprising, as SubgroupSize is a core part of SPIR-V (since version 1.1), while the intel_reqd_sub_group_size annotation is part of a (non-core) OpenCL vendor extension.

Attached are an example SPIR-V assembly kernel, along with the llvm IR that the translator emits by default. The pertinent sections are:

SPIR-V:

               OpEntryPoint Kernel %11 "kernel"
               OpExecutionMode %11 ContractionOff
; CHECK: !intel_reqd_sub_group_size [[METADATA:\![0-9]+]]
; CHECK: [[METADATA]] = !{i32 42} 
               OpExecutionMode %11 SubgroupSize 42

LLVM:

; Function Attrs: nounwind
define spir_kernel void @kernel(...) ... !intel_reqd_sub_group_size !15
...
!15 = !{i32 42}

Is this intended behaviour? I'm aware that a consumer of SPIR-V may not always go through the translator, but for consumers who do, it seems odd to translate to a vendor-specific OpenCL extension for a core language feature.

My opinion is that this should be changed so that it translates to a vendor-agnostic attribute, which vendors (or consumers) can translate into internal representations (such as intel's existing attribute), or implement directly.

I'd be keen to hear any background or rationale for the current implementation.

subgroup_size.spvasm.txt
subgroup_size_.spvasm.tmp.ll.txt

[MrSidims]

That is not a translation to "vendor-specific attribute" rather than a translation to a named LLVM IR metadata that is happened to have "intel" in its name as it's also produced by clang for the mentioned intel_reqd_sub_group_size.

Technically, since the translator has 2 modes: OpenCL and "SPIR-V friendly LLVM IR," we may change the behaviour for "SPIR-V friendly LLVM IR" translating SubgroupSize to "spirv.ExecutionMode XXX YYY" metadata, but I personally don't see current behaviour as a problem.

[AdamBrouwersHarries]

From a programmers perspective, I agree that this is just an implementation detail that is unlikely to be user-visible, and the name doesn't matter. From an implementors perspective, however, I feel a little uneasy, as right now implementing a SPIR-V/OpenCL based compiler requires that I (implicitly) implement something that looks like part of a vendor-specific OpenCL extension. In other words, to support a core SPIR-V feature, it looks like I (internally) support part of a vendor-specific extension.

My concern is that a lawyer somewhere will say "hey, you're using this string that comes from this Intel extension, therefore you are implementing the extension", and I will need to pay for a license to implement Intel's OpenCL extension - despite only implementing core SPIR-V functionality. A straightforward way to avoid this would be to simply drop the intel_ portion of the metadata name, even if the functionality remains the same.

[MrSidims]

a lawyer somewhere will say hey, you're using this string that comes from this Intel extension, therefore you are implementing the extension

I'm not a lawyer myself, so it's not a legal advice, but I would ask them to double check https://github.com/llvm/llvm-project/blob/main/LICENSE.TXT and https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/main/LICENSE.TXT (and optionally https://github.com/intel/llvm/blob/sycl/LICENSE.TXT) before making such claims.

I would ask Intel folks to comment on this (tagging @vmaksimo @YuriPlyakhin @bashbaug) but as I've said I see zero issues with this metadata usage.

[svenvh]

Discussed in the Khronos Tooling call of 21 May 2026: we should be able to drop the vendor prefix from the metadata name. We'll probably want a transition period where we emit both the old and new names.