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

Remove dependency on llvm-spirv package and use llvm-spirv from dpcpp #778

Closed
diptorupd opened this issue Sep 21, 2022 · 4 comments
Closed
Assignees
Milestone

Comments

@diptorupd
Copy link
Contributor

diptorupd commented Sep 21, 2022

Right now numba-dpex depends on the llvm-spirv package to generate SPIR-V from LLVM IR. Now that dpcpp compilers are available as Conda packages it should be possible to use the dpcpp package to get llvm-spirv.

We should add dpcpp as a build and run dependency and remove the need to install llvm-spirv separately.

But, tests should be done to ensure dpex still works for users who install it from pypi or build it from source without using conda. In that case, they are required to have llvm-spirv added to the PATH and dpex should have a run time check to see if the version requirements for llvm-spriv match our needs.

Most like #676 would also be fixed once we switch to using llvm-spirv from dpcpp.

@diptorupd diptorupd changed the title Remove ependency on llvm-spirv package and use llvm-spirv from dpcpp Remove dependency on llvm-spirv package and use llvm-spirv from dpcpp Sep 21, 2022
@diptorupd
Copy link
Contributor Author

An additional place where the fix should be applied is inside setup.py. The _llvm_spirv function assumes that we have dpcpp installed in a oneAPI folder and tries to use it from there.

@diptorupd
Copy link
Contributor Author

@mingjie-intel based on our discussion today, it will be best if dpex vendors llvm-spirv. The way we are doing it currently leaves us at mercy of user environment and is open to all sorts of issues.

@oleksandr-pavlyk If we vendor a copy of llvm-spirv with dpex, how will it work for wheels based distributions? Do you foresee any issues?

@oleksandr-pavlyk
Copy link
Contributor

I think there is no problem with vendoring. It is a stand-alone ELF file which only depends on standard libraries, and no symbolic links are involved,

(idp_2022.1) [08:42:15 ansatnuc04 dpnp]$ ldd /opt/intel/oneapi/compiler/latest/linux/bin-llvm/llvm-spirv
        linux-vdso.so.1 (0x00007ffc68d07000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa3f33ec000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa3f33e6000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa3f3297000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa3f3279000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa3f325e000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa3f323b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3f3049000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa3f3dd6000)
(idp_2022.1) [08:42:48 ansatnuc04 dpnp]$ file /opt/intel/oneapi/compiler/latest/linux/bin-llvm/llvm-spirv
/opt/intel/oneapi/compiler/latest/linux/bin-llvm/llvm-spirv: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped

@diptorupd
Copy link
Contributor Author

Done. numba-dpex now depends on the dpccp-llvm-spirv package.

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 a pull request may close this issue.

3 participants