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

CPU detection in distro build #793

Open
bmwiedemann opened this issue Nov 23, 2019 · 3 comments
Open

CPU detection in distro build #793

bmwiedemann opened this issue Nov 23, 2019 · 3 comments

Comments

@bmwiedemann
Copy link

@bmwiedemann bmwiedemann commented Nov 23, 2019

Related to #667, I found that with pocl-1.4, there is again CPU detection happening on the build machine.

The build environment has several significant diffs:

+++ pocl-1.4/build/sleef_config_temp_avx.h    2019-11-19 10:17:59.409588738 +000
0
@@ -3,4 +3,3 @@
 #define SLEEF_DOUBLE_VEC_AVAILABLE
 #define SLEEF_VINT_IS_VLONG
 #define SLEEF_VEC_128_AVAILABLE
-#define SLEEF_VEC_256_AVAILABLE

+++ pocl-1.4/build/sleef_config_temp_avx_fma4.h       2019-11-19 10:21:44.401592562 +0000
@@ -3,8 +3,3 @@
 #define SLEEF_DOUBLE_VEC_AVAILABLE
 #define SLEEF_VINT_IS_VLONG
 #define SLEEF_VEC_128_AVAILABLE
-#define HAVE_FMA32_128
-#define HAVE_FMA64_128
-#define SLEEF_VEC_256_AVAILABLE
-#define HAVE_FMA32_256
-#define HAVE_FMA64_256

Our build call is around line 100 of https://build.opensuse.org/package/view_file/openSUSE:Factory/pocl/pocl.spec

This bug was found as part of my work on reproducible builds for openSUSE.

@franz

This comment has been minimized.

Copy link
Contributor

@franz franz commented Dec 11, 2019

I could not reproduce, but the those lines removed in the diff should definitely be there.

The checks for CPU features are done in lib/kernel/host/CMakeLists.txt around line 400,
by calling clang with arguments like

--target=x86_64-pc-linux-gnu -D_CL_DISABLE_HALF -march=haswell -emit-llvm -ffp-contract=off -DDORENAME -DVEC512

on the source file lib/kernel/sleef/test.c.

there is again CPU detection happening on the build machine.

If by "CPU detection happening" you mean CMake generating of sleef_config_* headers, that has been there since pocl 1.0 or so, and it's independent of the host CPU when building with -DKERNELLIB_HOST_CPU_VARIANTS=distro.

@bmwiedemann

This comment has been minimized.

Copy link
Author

@bmwiedemann bmwiedemann commented Dec 11, 2019

-#define HAVE_FMA32_128
those lines removed in the diff should definitely be there

even if I build on a machine/CPU like qemu64 that does not support the FMA instruction?

From what I saw in my test results, something changed there with 1.4 over 1.3

@franz

This comment has been minimized.

Copy link
Contributor

@franz franz commented Dec 12, 2019

even if I build on a machine/CPU like qemu64 that does not support the FMA instruction?

If you're building a distro build, then yes, wherever you build. As you can see the clang arguments:

-march=haswell

which means Clang should always compile for (and report features for) Intel Haswell. Unlike -mtune argument which compiles for some generic CPU with tuning for a specific CPU.

A pocl "distro" build precompiles several kernel libraries for different hardcoded CPU names with -march. The available features of those CPUs are detected like i described in previous comment.

something changed there with 1.4 over 1.3

It seems your Clang reports incorrect CPU extensions for some reason. Possibly a bug in Clang or something else, but doesn't seems to be a bug in pocl (so far).

For "avx" kernel library, we use -march=sandybridge, and for "avx_fma4", we use -march=bdver1.

Try this command in your build environment:

clang --target=x86_64-pc-linux-gnu -D_CL_DISABLE_HALF -march=sandybridge -emit-llvm -ffp-contract=off -DDORENAME -DVEC256 -c lib/kernel/sleef/test.c

If it prints an error, your Clang (or build environment) is broken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.