Bug 1110722 - pocl uses compile-time CPU detection
pocl uses compile-time CPU detection
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Development
Other All
: P5 - None : Normal (vote)
: ---
Assigned To: Martin Hauke
E-mail List
Depends on:
Blocks: 1100677
  Show dependency treegraph
Reported: 2018-10-04 09:40 UTC by Bernhard Wiedemann
Modified: 2020-09-21 08:59 UTC (History)
1 user (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Wiedemann 2018-10-04 09:40:31 UTC
Steps to Reproduce:
osc co Factory/pocl && cd $_
osc build --no-service --vm-type=kvm --build-opt=--vm-custom-opt="-cpu qemu64"
+compare result to one without build-opt using
/usr/lib/build/pkg-diff.sh $rpm1 $rpm2

Was previously solved with

/usr/lib64/libpocl.so.2.2.0 differs in assembler output
--- /tmp/tmp.3iZr1DZRz5/tmp.MomrQD5u2D  2018-09-26 04:41:09.682694138 +0000
+++ /tmp/tmp.3iZr1DZRz5/tmp.3XC0iGKeQV  2018-09-26 04:41:09.750694493 +0000
@@ -93827,10 +93827,10 @@
        lea    offset(%rsp),%rdi
        lea    offset(%rsp),%rsi
        callq  <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_assignERKS4_@plt>
-       mov    %r12,%rax
-       sub    offset(%rsp),%rax
-       cmp    $something,%rax
-       jbe    <_ZL14kernel_libraryP13_cl_device_id + ofs>
+       mov    offset(%rsp),%rax
+       or     $something,%rax
+       cmp    %r12,%rax
+       je     <_ZL14kernel_libraryP13_cl_device_id + ofs>
        lea    offset(%rip),%rsi        #   <supported_image_formats + ofs>

In the build-root I can see:

/home/abuild/rpmbuild/BUILD/pocl-1.2/build/CMakeCache.txt      2033-10-28 17:46:42.015636815 +0000
@@ -411,7 +411,7 @@

 //The Host CPU to use with llc

 //LLVM assembler
@@ -837,7 +837,7 @@
 //Autodetected CPU

might be an upstream pocl bug, where the result of CPU detection
accidentally gets used during build
Comment 1 Bernhard Wiedemann 2018-10-04 10:16:02 UTC
Maybe related:

Binary files 5/.mount/home/abuild/rpmbuild/BUILD/pocl-1.2/build/lib/CL/CMakeFiles/lib_cl_llvm.dir/pocl_llvm_build.cc.o and 5b/.mount/home/abuild/rpmbuild/BUILD/pocl-1.2/build/lib/CL/CMakeFiles/lib_cl_llvm.dir/pocl_llvm_build.cc.o differ
Binary files .5/.mount/home/abuild/rpmbuild/BUILD/pocl-1.2/build/lib/CL/CMakeFiles/lib_cl_llvm.dir/pocl_llvm_utils.cc.o and 5b/.mount/home/abuild/rpmbuild/BUILD/pocl-1.2/build/lib/CL/CMakeFiles/lib_cl_llvm.dir/pocl_llvm_utils.cc.o differ
Binary files 5/.mount/home/abuild/rpmbuild/BUILD/pocl-1.2/build/lib/CL/devices/basic/CMakeFiles/pocl-devices-basic.dir/basic.c.o and 5b/.mount/home/abuild/rpmbuild/BUILD/pocl-1.2/build/lib/CL/devices/basic/CMakeFiles/pocl-devices-basic.dir/basic.c.o differ

and comparing objdump -d pocl_llvm_build.cc.o
shows the above diff

The compilation uses
/usr/bin/clang++   -I../lib/CL/../../fix-include/OpenCL -I../fix-include -I../include -I. -I../lib/CL/devices -I../lib/CL/. -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -DNDEBUG -O2 -g -DNDEBUG -fPIC   -Werror=implicit-function-declaration -I/usr/include -O2  -D_FORTIFY_SOURCE=0 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection  -fno-strict-aliasing -fPIC -fvisibility-inlines-hidden -std=c++11           -ffunction-sections -fdata-sections -O2 -g -DNDEBUG  -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I"/home/abuild/rpmbuild/BUILD/pocl-1.2/lib/CL/../llvmopencl" -MD -MT lib/CL/CMakeFiles/lib_cl_llvm.dir/pocl_llvm_build.cc.o -MF lib/CL/CMakeFiles/lib_cl_llvm.dir/pocl_llvm_build.cc.o.d -o lib/CL/CMakeFiles/lib_cl_llvm.dir/pocl_llvm_build.cc.o -c ../lib/CL/pocl_llvm_build.cc

so at least no explicit -march is used. Maybe a clang/llvm bug?
Comment 2 Bernhard Wiedemann 2018-10-04 10:19:20 UTC
Not a llvm bug, but

@@ -135,7 +135,7 @@

 /* used in lib/CL/devices/basic */
 #define OCL_KERNEL_TARGET  "x86_64-unknown-linux-gnu"
-#define OCL_KERNEL_TARGET_CPU  "haswell"
+#define OCL_KERNEL_TARGET_CPU  "pentium2"

being used in all 3 differing .o files:
lib/CL/devices/basic/basic.c:    dev->llvm_cpu = OCL_KERNEL_TARGET_CPU;
lib/CL/pocl_llvm_utils.cc:                   OCL_KERNEL_TARGET_CPU " for -target-cpu\n");
lib/CL/pocl_llvm_utils.cc:    r = llvm::StringRef(OCL_KERNEL_TARGET_CPU);
lib/CL/pocl_llvm_build.cc:    kernellib_fallback += OCL_KERNEL_TARGET_CPU;
Comment 3 Martin Pluskal 2018-10-04 11:01:44 UTC
Definitely not major issue
Comment 4 Bernhard Wiedemann 2018-10-08 15:40:58 UTC
Proposing this patch upstream:
Comment 5 Bernhard Wiedemann 2020-02-08 11:25:44 UTC
The PR had been merged, but pocl-1.4 had new compile-time CPU-detection:

This can cause crashes when compiled on new CPUs and run on old CPUs.
Comment 6 Bernhard Wiedemann 2020-09-21 08:59:41 UTC
When working with upstream, we found that the new CPU-dependency
is more of an artifact of that my tests use qemu64
and how llvm maps that to pentium2.

When comparing builds between -cpu=Opteron_G1 and host
there were no diffs, so counting it as fixed.