Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] spirv-link: allow linking functions with different pointer arguments #5534

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

karolherbst
Copy link
Contributor

Since llvm-17 there are no typed pointers and hte SPIRV-LLVM-Translator doesn't know the function signature of imported functions.

I'm investigating different ways of solving this problem and adding an option to work around it inside spirv-link is one of those.

The code is almost complete, just I'm having troubles constructing the bitcast to cast the pointer parameters to the final type.

If anybody here has any better ideas on how to fix this, please tell.

Some background:
Supporting this is useful for OpenCL implementations using SPIR-V binaries as the internal program representation and not using LLVM for backend compilation. spirv-link is used to link program objects together before handing it off into the backend compiler. It's just that llvm-17 dropping typed pointers broke several OpenCL C tests as constructing the extern function signature became impossible to do.

Since llvm-17 there are no typed pointers and hte SPIRV-LLVM-Translator
doesn't know the function signature of imported functions.

I'm investigating different ways of solving this problem and adding an
option to work around it inside `spirv-link` is one of those.

The code is almost complete, just I'm having troubles constructing the
bitcast to cast the pointer parameters to the final type.
Copy link
Contributor

@pierremoreau pierremoreau left a comment

Choose a reason for hiding this comment

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

A few modifications to be made, commented in line.

New unit tests would also be needed:

  1. testing that a mismatch in pointers is not rejected when the flag is set,
  2. and is still rejected when it is not.
  3. Setting the flag still rejects a mismatch between a pointer and a non-pointer.

Otherwise, the change looks reasonable to me.

@@ -815,21 +882,27 @@ spv_result_t Link(const Context& context, const uint32_t* const* binaries,
&linked_context);
if (res != SPV_SUCCESS) return res;

// Phase 10: Compact the IDs used in the module
// Phase 10: Optionall fix function call types
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// Phase 10: Optionall fix function call types
// Phase 10: Optional fix function call types

const auto& exported_param = exported_params[i];

if (!imported_param->IsSame(exported_param) &&
imported_param->kind() != Type::kPointer &&
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
imported_param->kind() != Type::kPointer &&
!(imported_param->kind() == Type::kPointer &&

The previous code would result in correct == false for imported_param being a pointer, and exported_param being a structure (for example)

Maybe even change to !(imported_param->isSame(exported_param) || (imported_param->kind() == Type::kPointer && exported_param->kind() == Type::kPointer))


if (!imported_param->IsSame(exported_param) &&
imported_param->kind() != Type::kPointer &&
exported_param->kind() != Type::kPointer) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
exported_param->kind() != Type::kPointer) {
exported_param->kind() == Type::kPointer)) {

// - get target type id
// - insert instruction
// - replace operand
new Instruction(&context, spv::Op::OpBitcast, ..., 0u, {{SPV_OPERAND_TYPE_ID, arg.AsId()}});
Copy link
Contributor

Choose a reason for hiding this comment

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

I do not think this will compile as-is, and a res_id of 0 seems wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, that's why I put the comments on top because I was kinda stuck there

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.

None yet

2 participants