Skip to content

Conversation

@pvelesko
Copy link

This PR adds validation support for three Intel SPIR-V extensions:

OpConstantFunctionPointerINTEL: Added validation logic and test coverage
ArbitraryPrecisionIntegersINTEL: Added type validation support and tests
OpAliasScopeDeclINTEL/OpAliasScopeListDeclINTEL: Added ID validation support and tests

Fixes #6034

@CLAassistant
Copy link

CLAassistant commented Jul 27, 2025

CLA assistant check
All committers have signed the CLA.

@alan-baker
Copy link
Contributor

Please sign the CLA. Could you also link to the extension text for constant function pointers and alias scopes? I couldn't see them on the SPIRV-Registry.

@pvelesko
Copy link
Author

@alan-baker I can't find info on these extensions but I encountered them in the wild.

Perhaps @bashbaug can shed some light?

@bashbaug
Copy link
Contributor

SPV_INTEL_function_pointers

SPV_INTEL_memory_access_aliasing

These aren't published on the registry since we still consider them "preview extensions", though if you're encountering them in the wild then we really ought to get them finalized and published on the registry.

spv_result_t ValidateConstantFunctionPointerINTEL(ValidationState_t& _,
const Instruction* inst) {
// Check that the FunctionPointersINTEL capability is present
if (!_.HasCapability(spv::Capability::FunctionPointersINTEL)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this ought to be unnecessary. It should be checked during parsing.


// Validate the result type is a function pointer
const auto result_type = _.FindDef(inst->type_id());
if (!result_type || result_type->opcode() != spv::Op::OpTypePointer) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Result must be a pointer type. If it is OpTypePointer (i.e. not OpTypeUntypedPointerKHR) then it must match match the one used for the function operand. So basically, this doesn't handle the untyped pointer case.

// Validate that the function operand exists
const uint32_t function_id = inst->GetOperandAs<uint32_t>(2);
const auto function_inst = _.FindDef(function_id);
if (!function_inst) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually happening? This indicates there's no instruction for this id. At this point in the flow I don't think that's possible.

}

// Validate that the function operand refers to an OpFunction
if (function_inst->opcode() != spv::Op::OpFunction) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec seems unclear to me here (since it neglects to properly describe this operand), but I thought it must be a function pointer. @bashbaug thoughts?

Comment on lines +95 to +96
if (_.HasCapability(spv::Capability::FunctionPointersINTEL))
acceptable.push_back(spv::Op::OpConstantFunctionPointerINTEL);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since parsing is gated on the capability already then I think you can just add this to the list unconditionally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

spirv-val doesn't know about SPV_INTEL_arbitrary_precision_integers

4 participants