Call to textureWeightedQCOM invalid when used in a function

[s-perron]

See https://godbolt.org/z/znxjz5e7M for an example. Note that the validator does not complain, but I still think it is invalid. Here is a snippet that I think shows the problem:

OpDecorate %wTex WeightTextureQCOM
...
         %41 = OpFunctionCall %v4float %foo_tA21_p1_s21_ %weightsTex %weightsSampler %sampleTex
...
%foo_tA21_p1_s21_ = OpFunction %v4float None %16
       %wTex = OpFunctionParameter %_ptr_UniformConstant_8  
   %wSampler = OpFunctionParameter %_ptr_UniformConstant_10
       %sTex = OpFunctionParameter %_ptr_UniformConstant_13
...
         %29 = OpLoad %8 %wTex
         %31 = OpLoad %10 %weightsSampler
         %33 = OpSampledImage %32 %29 %31
         %34 = OpImageSampleWeightedQCOM %v4float %27 %28 %33

Note that %weightsTex is not decorated with WeightTextureQCOM.

Here is where I think the problem is. In the SPV_QCOM_image_processing spec, it describes the weights as:

Weight Image must be an object whose type is OpTypeSampledImage. If the object is an interface object, it must be decorated with WeightTextureQCOM. Otherwise, a texture object which is used to construct the object must be decorated with WeightTextureQCOM. The MS operand of the underlying OpTypeImage must be 0.

The problem is that even though %wTex is decorated with WeightTextureQCOM, I don't consider that the object used to construct the sampled image. That would be the parameter on the function call, %weightsTex, which is not decorated.

Note the defintion of object in the SPIR-V spec:

Object: An instantiation of a non-void type, either as the Result of an operation, or created through OpVariable.

%wtex is not the result of an operation, not is it created through an OpVariable.

This was found because spirv-opt's inliner replaces the operand in the OpImageSampleWeightedQCOM instruction, and %wTex disappears. Then the validator complains.