Using the half type does not generate the Float16 capability

[bashbaug]

Found while reviewing KhronosGroup/SPIRV-Tools#6009.

Surprisingly, using the half type does not generate SPIR-V modules that declare the Float16 capability. We have some tests that are checking that the right capability is declared, for example:

SPIRV-LLVM-Translator/test/half_extension.ll

Line 17 in 4eea290

; CHECK-SPIRV-DAG: {{[0-9]+}} Capability Float16

However, this is unfortunately matching Capability Float16Buffer, so it is not actually checking for Capability Float16. If I change this check instead to:

; CHECK-SPIRV: Capability {{Float16 *$}}

Then the test starts to fail.

Recommended actions:

1. Change all tests to check for Float16 at the end of the line, similar to the check above.
   • Are there any other capabilities that are the prefix of another capability that may be affected similarly?
2. Figure out why Float16Buffer is being declared and not Float16. Possibly something is going wrong here?

SPIRV-LLVM-Translator/lib/SPIRV/libSPIRV/SPIRVType.h

Lines 214 to 224 in 4eea290

	SPIRVCapVec getRequiredCapability() const override {
	SPIRVCapVec CV;
	if (isTypeFloat(16)) {
	CV.push_back(CapabilityFloat16Buffer);
	auto Extensions = getModule()->getSourceExtension();
	if (std::any_of(Extensions.begin(), Extensions.end(),
	[](const std::string &I) { return I == "cl_khr_fp16"; }))
	CV.push_back(CapabilityFloat16);
	} else if (isTypeFloat(64))
	CV.push_back(CapabilityFloat64);
	return CV;

[svenvh]

If I change this check instead to:

; CHECK-SPIRV: Capability {{Float16 *$}}

Then the test starts to fail.

I am struggling to reproduce the issue. The .spt output resulting from test/half_extension.ll does declare both Float16 and Float16Buffer, which looks right to me. The current CHECK-SPIRV-DAG directives catch both as far as I can tell, and not just one.

2. Figure out why Float16Buffer is being declared and not Float16. Possibly something is going wrong here?
   SPIRV-LLVM-Translator/lib/SPIRV/libSPIRV/SPIRVType.h

The cl_khr_fp16 extension condition was added by KhronosGroup/SPIRV-LLVM#167 (long ago).

[bashbaug]

Hmm, I may have simplified my test case a bit too much. This is what I was using to observe the problem:

; RUN: llvm-as %s -o %t.bc
; RUN: llvm-spirv %t.bc -spirv-text -o - | FileCheck %s --check-prefixes=CHECK-SPIRV

; CHECK-SPIRV: Capability {{Float16 *$}}

target triple = "spir64-unknown-unknown"

define half @f1(half %a) {
  ret half %a
}

This is fairly representative what comes out of Clang, though. If I start from this test case https://godbolt.org/z/3K5brqMv8 and compile via a recent Clang and the latest SPIR-V LLVM Translator:

$ clang-20 -c -emit-llvm -cl-std=CL3.0 --target=spirv64 simple_fp16.cl
$ llvm-spirv simple_fp16.bc --spirv-ext=+all -o simple_fp16.spv

I get the following SPIR-V module, which declares Float16Buffer and not Float16:

$ spirv-dis simple_fp16.spv
; SPIR-V
; Version: 1.0
; Generator: Khronos LLVM/SPIR-V Translator; 14
; Bound: 17
; Schema: 0
               OpCapability Addresses
               OpCapability Linkage
               OpCapability Kernel
               OpCapability Float16Buffer
               OpCapability UntypedPointersKHR
               OpExtension "SPV_KHR_untyped_pointers"
          %1 = OpExtInstImport "OpenCL.std"
               OpMemoryModel Physical64 OpenCL
               OpEntryPoint Kernel %12 "test"
               OpExecutionMode %12 ContractionOff
               OpSource OpenCL_C 300000
               OpName %test "test"
               OpDecorate %test LinkageAttributes "test" Export
               OpDecorate %7 FuncParamAttr NoCapture
               OpDecorate %7 Alignment 2
               OpDecorate %13 FuncParamAttr NoCapture
               OpDecorate %13 Alignment 2
       %void = OpTypeVoid
       %half = OpTypeFloat 16
%_ptr_CrossWorkgroup = OpTypeUntypedPointerKHR CrossWorkgroup
          %5 = OpTypeFunction %void %_ptr_CrossWorkgroup %half
%half_0x1p_0 = OpConstant %half 0x1p+0
       %test = OpFunction %void None %5
          %7 = OpFunctionParameter %_ptr_CrossWorkgroup
          %8 = OpFunctionParameter %half
          %9 = OpLabel
         %11 = OpFAdd %half %8 %half_0x1p_0
               OpStore %7 %11 Aligned 2
               OpReturn
               OpFunctionEnd
         %12 = OpFunction %void None %5
         %13 = OpFunctionParameter %_ptr_CrossWorkgroup
         %14 = OpFunctionParameter %half
         %15 = OpLabel
         %16 = OpFunctionCall %void %test %13 %14
               OpReturn
               OpFunctionEnd

And, it also fails the new validation checks:

$ spirv-val simple_fp16.spv 
error: line 27: Invalid use of 8- or 16-bit result
  %11 = OpFAdd %half %8 %half_0x1p_0

Based on the code snip I included in the issue description, the key difference seems to be this metadata for cl_khr_fp16, which is present in the passing LIT test but missing in my simplified test and the LLVM IR from Clang:

!opencl.used.extensions = !{!1}
!1 = !{!"cl_khr_fp16"}

Should Clang be inserting this metadata somehow? Or should the SPIR-V LLVM Translator be using some other mechanism to determine whether to declare the Float16 capability?

[svenvh]

Ah, I see now. opencl.used.extensions seems to be a relic from the old SPIR that clang doesn't generate (and rightfully so, I suppose). I think we should improve the translator's mechanism for determining whether to declare the Float16 capability.