Low Level Virtual Machine

Edit Package llvm17

LLVM is a compiler infrastructure designed for compile-time, link-time, runtime, and idle-time optimization of programs from arbitrary programming languages.

The compiler infrastructure includes mirror sets of programming tools as well as libraries with equivalent functionality.

Refresh
Refresh
Source Files
Filename Size Changed
_constraints 0000001002 1002 Bytes
assume-opensuse.patch 0000001186 1.16 KB
baselibs.conf 0000000025 25 Bytes
check-no-llvm-exegesis.patch 0000000276 276 Bytes
clang-17.0.6.src.tar.xz 0021577596 20.6 MB
clang-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
clang-Fix-build-with-GCC-14-on-ARM.patch 0000002708 2.64 KB
clang-docs-17.0.6.src.tar.xz 0001615064 1.54 MB
clang-resourcedirs.patch 0000000587 587 Bytes
clang-tools-extra-17.0.6.src.tar.xz 0003269980 3.12 MB
clang-tools-extra-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
cmake-17.0.6.src.tar.xz 0000008712 8.51 KB
cmake-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
compact_unwind_encoding.h 0000019091 18.6 KB
compiler-rt-17.0.6.src.tar.xz 0002421808 2.31 MB
compiler-rt-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
default-to-i586.patch 0000000472 472 Bytes
libcxx-17.0.6.src.tar.xz 0003946532 3.76 MB
libcxx-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
libcxx-test-library-path.patch 0000000708 708 Bytes
libcxxabi-17.0.6.src.tar.xz 0000575744 562 KB
libcxxabi-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
lld-17.0.6.src.tar.xz 0001506048 1.44 MB
lld-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
lld-default-sha1.patch 0000002564 2.5 KB
lldb-17.0.6.src.tar.xz 0010493512 10 MB
lldb-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
lldb-cmake.patch 0000000504 504 Bytes
llvm-17.0.6.src.tar.xz 0059298244 56.6 MB
llvm-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
llvm-do-not-install-static-libraries.patch 0000005826 5.69 KB
llvm-docs-17.0.6.src.tar.xz 0007138248 6.81 MB
llvm-fix-find-gcc5-install.patch 0000000613 613 Bytes
llvm-normally-versioned-libllvm.patch 0000003317 3.24 KB
llvm-projects-tools-order.patch 0000000421 421 Bytes
llvm-remove-clang-only-flags.patch 0000001135 1.11 KB
llvm-suse-implicit-gnu.patch 0000000625 625 Bytes
llvm-workaround-superfluous-branches.patch 0000000567 567 Bytes
llvm17-rpmlintrc 0000001048 1.02 KB
llvm17.changes 0000117966 115 KB
llvm17.keyring 0000006354 6.21 KB
llvm17.spec 0000063465 62 KB
llvm_build_tablegen_component_as_shared_library.patch 0000002925 2.86 KB
lto-disable-cache.patch 0000001476 1.44 KB
openmp-17.0.6.src.tar.xz 0001273412 1.21 MB
openmp-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
openmp-dont-run-gpu-arch.patch 0000000587 587 Bytes
opt-viewer-Find-style-css-in-usr-share.patch 0000000672 672 Bytes
polly-17.0.6.src.tar.xz 0009219324 8.79 MB
polly-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
runtimes-17.0.6.src.tar.xz 0000006240 6.09 KB
runtimes-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
tests-use-python3.patch 0000001007 1007 Bytes
third-party-17.0.6.src.tar.xz 0000383752 375 KB
third-party-17.0.6.src.tar.xz.sig 0000000438 438 Bytes
Comments 8

Chemal Pemial's avatar

libomptarget.devicertl.a shouldn't be removed but packaged whenever it gets built. It's a necessary component for linking openmp programs with offloading to an AMD or NVIDIA GPU.

--- llvm17.spec.orig    2023-10-26 16:49:43.920727185 +0200
+++ llvm17.spec 2023-10-26 16:53:55.748799132 +0200
@@ -1253,8 +1253,6 @@
 rm %{buildroot}%{_libdir}/libgomp.so
 rm %{buildroot}%{_libdir}/libiomp*.so
 rm %{buildroot}%{_libdir}/libarcher_static.a
-# Using -f because this isn't built for all architectures for some reason.
-rm -fv %{buildroot}%{_libdir}/libomptarget.devicertl.a
 %endif

 # Prepare for update-alternatives usage
@@ -1672,6 +1670,7 @@
 %{_libdir}/libomptarget-amdgpu-*.bc
 %{_libdir}/libomptarget-nvptx-*.bc
 %ifarch aarch64 ppc64le x86_64
+%{_libdir}/libomptarget.devicertl.a
 %{_libdir}/libomptarget.rtl.{%{host_cpu},amdgpu,cuda}.so
 %{_libdir}/libomptarget.rtl.{%{host_cpu},amdgpu,cuda}.so.%{_soname}
 %endif

Aaron Puchert's avatar

We usually don't ship static libraries, but if that's all that's required it would probably be fine to include it. However, it would be nice if you could check:

  • Can we build this as shared library, or is there a good reason why it is static (e.g. it is rather small)?
  • Does it actually work with that library, or is something else needed as well?


Chemal Pemial's avatar

libomptarget.devicertl.a is 8.4M and contains code for the offload targets (all supported AMD and NVIDIA GPUs). It certainly can't be a shared library.

Here's sort of a "hello world" for openmp offloading:

#include <stdio.h>
#include <omp.h>

int main() 
{
    int num_devices = omp_get_num_devices();
    printf("Number of available devices %d\n", num_devices);

#pragma omp target 
    {
        if (omp_is_initial_device()) {
            printf("Running on host\n");    
        } else {
            int nteams= omp_get_num_teams(); 
            int nthreads= omp_get_num_threads();
            printf("Running on device with %d teams in total and %d threads in each team\n",nteams,nthreads);
        }
    }
}

Compile with clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda h.c and you get a linker error, because libomptarget.devicertl.a cannot be found. If you have this file, the linking stage succeeds. The executable works as expected. I've even checked (with nvprof from the CUDA SDK) that there is really code running on the GPU.

Finally, I've tested a couple of more interesting programs. Everything is fine, once the missing library is available.


Aaron Puchert's avatar

libomptarget.devicertl.a is 8.4M and contains code for the offload targets (all supported AMD and NVIDIA GPUs).

That is rather large compared to the remainder of libomp17-devel, but I guess it's Ok.

It certainly can't be a shared library.

Why not?

Thanks for confirming that it works. I guess I'll include the file with the next update then.


Chemal Pemial's avatar

Why not?

$ llvm-objdump --offloading libomptarget.devicertl.a

OFFLOADING IMAGE [0]:
kind            llvm ir
arch            sm_35
triple          nvptx64-nvidia-cuda
producer        openmp

...

It's LLVM IR put into object files and then packed into an archive.


Aaron Puchert's avatar

Understood, so it's bitcode for the individual offload targets packaged into one archive. I always thought that the target-dependent code lived in %{_libdir}/libomptarget-*.bc, which we also package, since they have the usual ending for bitcode files. Do you know what role they play?


Chemal Pemial's avatar

If I read the build process properly, this archive is indeed directly created from the bitcode files. I don't know why they are installed, too. Backward compatibility? (Fedora and Debian also package the archive and the bitcode files.)

openSUSE Build Service is sponsored by