Skip to content

Fix translation of read_image* built-ins to SPIR-V #408

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

Conversation

AlexeySachkov
Copy link
Contributor

There are several overloads of read_image function defined by OpenCL C
spec, but all of them use the same SPIR-V instruction, so, we need to
add one more optional postfix to differentiate instructions with the
same argument types, but different return types.

Example:

  • int4 read_imagei(image2d_t, sampler_t, int2)
  • uint4 read_imageio(image2d_t, sampler_t, int2)

Both functions above are represented by the same SPIR-V instruction and
we need to distinguish them in SPIR-V friendly LLVM IR.

if (OC == OpImageRead) {
// There are several read_image* functions defined by OpenCL C spec, but
// all of them use the same SPIR-V Instruction - some of them might only
// differ by return type, so, we need to include return type into the
Copy link
Member

Choose a reason for hiding this comment

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

Including the return type in the mangled name does not sound like the correct way to handle this issue.

SPIR-V 1.4 adds the SignExtend and ZeroExtend image operands. It would be better to make use of those somehow.

We have a downstream patch that uses a single bit in the image operands to disambiguate. I could try to upstream that instead if you are interested, but it will require a bit of rework and it will not be conformant to any pre-1.4 spec.

Copy link
Contributor

Choose a reason for hiding this comment

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

We also should disambiguate between the following 2 function calls:

uint4 c = read_imageui(input, (int4)(0, 0, 0, 0));
float4 f = read_imagef(input, (int4)(0, 0, 0, 0));

I don't think the image operands can help to represent these calls in SPIR-V-friendly LLVM IR.

Copy link
Member

Choose a reason for hiding this comment

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

Ah sorry, I didn't realize this was only about the SPIR-V representation in LLVM IR.

LGTM then!

if (OC == OpImageRead) {
// There are several read_image* functions defined by OpenCL C spec, but
// all of them use the same SPIR-V Instruction - some of them might only
// differ by return type, so, we need to include return type into the
Copy link
Member

Choose a reason for hiding this comment

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

Ah sorry, I didn't realize this was only about the SPIR-V representation in LLVM IR.

LGTM then!

There are several overloads of read_image function defined by OpenCL C
spec, but all of them use the same SPIR-V instruction, so, we need to
add one more optional postfix to differentiate instructions with the
same argument types, but different return types.

Example:
- int4 read_imagei(image2d_t, sampler_t, int2)
- float4 read_imagef(image2d_t, sampler_t, int2)

Both functions above are represented by the same SPIR-V instruction and
we need to distinguish them in SPIR-V friendly LLVM IR.
@AlexeySachkov AlexeySachkov force-pushed the private/asachkov/fix-read-image-translation branch from 1be672f to 51808d4 Compare January 16, 2020 15:12
@AlexeySotkin AlexeySotkin merged commit 129232c into KhronosGroup:master Jan 17, 2020
@AlexeySachkov AlexeySachkov deleted the private/asachkov/fix-read-image-translation branch April 1, 2020 14:43
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.

3 participants