Skip to content

Conversation

@diptorupd
Copy link
Contributor

numba-dpex does not pin the max-spirv-version that llvm-spirv generates and lets llvm-spriv decide what SPIR-V code to generate based on the LLVM-IR generated by the Numba front-end.

The behaviour is causing an issue with oneAPI dpcpp 2023.0 (Refer #868). The issue arises when a pre-compiled SPIR-V binary produced by compiling an OpenCL program implementing software atomic add for floating point values is linked to the SPIR-V module generated by JIT compilation inside numba-dpex.

The PR implements a workaround by setting the spirv-max-version flags to 1.1 when generating SPIR-V both for the pre-compiled OpenCL program and inside numba-dpex. SPIR-V version 1.1 is used as it seems to be the default used by dpcpp.

@diptorupd
Copy link
Contributor Author

Merging as the commit has already been tested in #880

@diptorupd diptorupd merged commit acacdbe into main Jan 22, 2023
@diptorupd diptorupd deleted the pin_spirv_max_version branch January 22, 2023 02:58
github-actions bot added a commit that referenced this pull request Jan 22, 2023
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.

1 participant