[Pkg-opencl-devel] pocl packaging

Andreas Beckmann anbe at debian.org
Fri Feb 23 14:46:15 UTC 2018 

Hi,

On 2018-02-21 18:45, Michal Babej wrote:
> pocl developer here. I have a few questions/suggestions for Debian's pocl packager(s).

> 1) are you aware of https://github.com/pocl/pocl/blob/master/README.packaging ? I have updated it for 1.0 with a few things packagers might find useful..

Yes.

-DENABLE_POCL_BUILDING=OFF sounds like a useful idea, but it breaks
running the tests during the build (since nothing is in the "installed"
location, yet).

> 2) I see Debian carrying about a dozen patches, which by quick look seem useful, but nobody has ever mentioned them to the pocl team ? We're generally quite receptive of bugfixes but we need to know about them.. 

The ones that should be immediately useful for you are
* consistent-newlines-in-POCL_ABORT.patch
* typos.patch
I didn't check whether 1.1rc1 introduces new POCL_ABORT() without \n
New typo in 1.1rc1 doc/sphinx/source/install.rst:
  s/overriden/overridden/

Why does pocl still set -fno-rtti for all llvm versions?
I didn't have any problems after disabling it, using llvm 3.8, 3.9, 4.0,
5.0, 6.0 ... the comments indicate a workaround for an ancient bug
(I primarily disabled it to avoid symbol changes noise while switching
from autotools to cmake some versions ago)

> 3) what problem are you trying to solve with FORCE_OCL_KERNEL_TARGET_CPU.patch ? the "official" way to force a specific CPU is -DLLC_HOST_CPU=<something>, i'm currently using it for occasional ARM builds; if it doesn't work on some setup, i'd like to hear about it

By default pocl does the equivalent of a -march=native build at both
compile time and runtime. This is a no-go for a distribution. We need to
build everything s.t. it runs on the baseline cpu for each architecture
(and not only on the likely more powerful cpu in the buildd machine,
which will even differ from machine to machine).
(But programs may ship routines optimized for different cpus and and do
runtime cpu detection to select what's best).
Ideally this is done by using the compiler defaults, i.e. not passing
any -mcpu/-march/-mavxyz flags, but I didn't find a way to hint pocl to
do this. So I'm trying to find out what's the correct baseline cpu for
each architecture to pass that as -DLLC_HOST_CPU ...

Next is running pocl, which again does runtime cpu detection and
optimizes for the current host. Which does not seem to be always
compatible with the baseline kernellib (e.g. i386 chroot on amd64
(ivybridge) machine, building with -DLLC_HOST_CPU=i686). Here comes
FORCE_OCL_KERNEL_TARGET_CPU.patch into play, it disables the runtime cpu
detection and uses the -DLLC_HOST_CPU setting there as well.
I know this results in suboptimal pocl performance, but at least we have
something generating reproducible results independent of the hardware
used. And from there on, we could improve things ...

This also makes filing bug reports for test failures more difficult
since it is essentially "test X fails for pocl compiled with options
-DFOO -DBAR on $(cat /proc/cpuinfo)".

> 4) if possible, on x86-64 please build with "-DKERNELLIB_HOST_CPU_VARIANTS=distro"  instead of forcing a specific CPU. This results in vastly more useful build (and one that should work on almost every x86-64 machine). Both Fedora and OpenSUSE build with this option on x86-64 and i have not heard of any issues, if Debian runs into any, please let us know...

This is on my TODO, but first the baseline has to work properly :-)
And the interesting question is: how to test the different kernel
libraries (and cpu targets)? Given a modern cpu in the build machine, it
should be able run tests for all "older" cpus where it is a superset of
the features.

I did a quick test of 1.1rc1 yesterday and didn't find any regressions
compared to 1.0 with my setup :-)

And now I'll try to find time to file a bug for the i386 test_fabs
failure that I had ignored so far ... and the test regression on i386
when switching from llvm 4.0 to llvm 5.0.

-----

So far, we only got successful pocl builds for Debian on amd64 and i386:

https://buildd.debian.org/status/package.php?p=pocl&suite=unstable

arm* and s390x will hopefully improve the situation after the next upload.

But we also have failues where nobody found the time to investigate them
further. I'm mentioning them here in case you heard about them already
and have a pointer ...

mips*:

cd /<<PKGBUILDDIR>>/obj-mips-linux-gnu/lib/kernel/host &&
/usr/bin/clang-4.0 --target=mips-unknown-linux-gnu -D_CL_DISABLE_HALF
-march=mips32r2 -emit-llvm -ffp-contract=off -D__OPENCL_VERSION__=120
-Dcl_khr_int64 -Dcl_khr_global_int32_base_atomics
-Dcl_khr_local_int32_base_atomics -Dcl_khr_3d_image_writes -Xclang
-cl-ext=-all,+cl_khr_global_int32_base_atomics,+cl_khr_local_int32_base_atomics,+cl_khr_3d_image_writes,
-xc -D__CBUILD__ -fno-stack-protector -fno-PIC -o
/<<PKGBUILDDIR>>/obj-mips-linux-gnu/lib/kernel/host/mips32r2/printf.c.bc
-c /<<PKGBUILDDIR>>/lib/kernel/printf.c -include
/<<PKGBUILDDIR>>/include/_kernel_c.h
In file included from /<<PKGBUILDDIR>>/lib/kernel/printf.c:31:
In file included from /usr/include/math.h:224:
/usr/include/mips-linux-gnu/bits/mathcalls.h:267:55: error: expected ')'
__MATHCALLX (nexttoward,, (_Mdouble_ __x, long double __y), (__const__));
                                                      ^
/usr/include/mips-linux-gnu/bits/mathcalls.h:267:27: note: to match this '('
__MATHCALLX (nexttoward,, (_Mdouble_ __x, long double __y), (__const__));
                          ^
/usr/include/mips-linux-gnu/bits/mathcalls.h:267:55: error: expected ')'
__MATHCALLX (nexttoward,, (_Mdouble_ __x, long double __y), (__const__));
                                                      ^
/usr/include/mips-linux-gnu/bits/mathcalls.h:267:27: note: to match this '('
__MATHCALLX (nexttoward,, (_Mdouble_ __x, long double __y), (__const__));
                          ^
ppc64el:

cd /<<PKGBUILDDIR>>/obj-powerpc64le-linux-gnu/lib/kernel/host &&
/usr/bin/clang-4.0 --target=powerpc64le-unknown-linux-gnu
-D_CL_DISABLE_HALF -march=ppc64le -emit-llvm -ffp-contract=off -Wall
-Wno-unused-local-typedef -Xclang -cl-std=CL1.2
-D__OPENCL_C_VERSION__=120 -x cl -fno-stack-protector -fno-PIC
-D__OPENCL_VERSION__=120 -Dcl_khr_int64
-Dcl_khr_global_int32_base_atomics -Dcl_khr_local_int32_base_atomics
-Dcl_khr_3d_image_writes -Xclang
-cl-ext=-all,+cl_khr_global_int32_base_atomics,+cl_khr_local_int32_base_atomics,+cl_khr_3d_image_writes,
-o
/<<PKGBUILDDIR>>/obj-powerpc64le-linux-gnu/lib/kernel/host/ppc64le/abs.cl.bc
-c /<<PKGBUILDDIR>>/lib/kernel/abs.cl -include
/<<PKGBUILDDIR>>/include/_kernel.h -include
/<<PKGBUILDDIR>>/include/_enable_all_exts.h
clang: warning: argument unused during compilation: '-march=ppc64le'
[-Wunused-command-line-argument]
In file included from
/usr/lib/llvm-4.0/include/llvm/Support/DataTypes.h:33:0,
                 from /usr/lib/llvm-4.0/include/llvm/ADT/Hashing.h:48,
                 from /usr/lib/llvm-4.0/include/llvm/ADT/ArrayRef.h:13,
                 from /usr/lib/llvm-4.0/include/llvm/IR/IRBuilder.h:18,
                 from /<<PKGBUILDDIR>>/lib/llvmopencl/Kernel.cc:31:
/usr/include/c++/7/cmath: In function 'constexpr __vector(4) __bool int
std::isfinite(float)':
/usr/include/c++/7/cmath:570:34: error: cannot convert 'int' to
'__vector(4) __bool int' in return
   { return __builtin_isfinite(__x); }
                                  ^
/usr/include/c++/7/cmath:570:37: error: body of constexpr function
'constexpr __vector(4) __bool int std::isfinite(float)' not a
return-statement
   { return __builtin_isfinite(__x); }
                                     ^
...

and

In file included from /usr/include/c++/7/bits/uniform_int_dist.h:35:0,
                 from /usr/include/c++/7/bits/stl_algo.h:66,
                 from /usr/include/c++/7/algorithm:62,
                 from /usr/lib/llvm-4.0/include/llvm/ADT/STLExtras.h:20,
                 from /usr/lib/llvm-4.0/include/llvm/ADT/StringRef.h:13,
                 from /usr/lib/llvm-4.0/include/llvm/ADT/StringMap.h:17,
                 from /usr/lib/llvm-4.0/include/llvm/Support/Host.h:17,
                 from /usr/lib/llvm-4.0/include/llvm/ADT/Hashing.h:49,
                 from /usr/lib/llvm-4.0/include/llvm/ADT/ArrayRef.h:13,
                 from /usr/lib/llvm-4.0/include/llvm/IR/IRBuilder.h:18,
                 from /<<PKGBUILDDIR>>/lib/llvmopencl/Kernel.cc:31:
/usr/include/c++/7/limits: At global scope:
/usr/include/c++/7/limits:206:57: error: cannot convert 'bool' to 'const
__vector(4) __bool int' in initialization
     static _GLIBCXX_USE_CONSTEXPR bool is_specialized = false;
                                                         ^~~~~
...

This looks like a macro messed up the bool type ...


Andreas

More information about the Pkg-opencl-devel mailing list