Repository navigation
Support of PPC64 and S390x #2406
Description
Activity
- How are the s390x/ppc64 machine specific code maintained under
ops/ppc_vsx-inl.h? is this maintained and tested by google or the community? or is it copied from another source? We also support AIX (big endian ppc64) and need to figure out how we can add support for it if needed.
hwy/ops/ppc_vsx-inl.h is maintained by the community and tested using QEMU on Linux.
hwy/ops/ppc_vsx-inl.h was implemented by porting over hwy/ops/x86_128-inl.h from SSE2/SSSE3/SSE4/AVX2/AVX512 intrinsics to Altivec/VSX intrinsics (and later extended to include ZVector intrinsics) along with some platform-specific optimizations for Altivec/VSX/ZVector targets.
Here are the Google Highway targets for Power/ZSeries:
- PPC8 - Altivec + VSX + POWER8 vector instructions
- PPC9 - Altivec + VSX + POWER9 vector instructions
- PPC10 - Altivec + VSX + POWER10 vector instructions
- Z14 - ZVector on Z14 or later
- Z15 - ZVector on Z15 or later
The PPC8/PPC9/PPC10 targets support both little-endian ppc64 and big-endian ppc64.
There are compiler bugs with the PPC8/PPC9/PPC10 targets on big-endian ppc64 with Clang 16.0.0 or earlier that was fixed in Clang 16.0.1.
There are also compiler bugs with the Z14/Z15 targets with Clang 18 or earlier that were fixed in Clang 19.
Even though Google Highway dynamic dispatch is not currently implemented for AIX (or any ppc64 OS other than Linux), Google Highway should compile on AIX (or any non-Linux OS running on ppc64) with GCC 11 or later or Clang 16.0.1 or later.
It is possible to detect support for the PPC8/PPC9/PPC10 targets on AIX by checking the value of
_system_configuration.implementation.- How are the s390x/ppc64 machine specific code maintained under
Hi @miladfarca ,
The asm/hwcap.h is a workaround for some systems. Yes, it is safe to setTOOLCHAIN_MISS_ASM_HWCAP_H.
Do your compilers support__has_include? If so, we can use that to prevent the error, without requiring CMake/CXXFLAGS changes. We'd welcome a patch that adds that.Thank you both for the detailed information, I've made this CL to set TOOLCHAIN_MISS_ASM_HWCAP_H on our platforms: https://crrev.com/c/6092569
We only use gcc on native platforms (gcc 12 at the moment). I will close this issue and will create new issues/PRs if needed.Reacted by Jan Wassenberg- added a commit that references this issue
on Dec 13, 2024 Hi @jan-wassenberg,
Wanted to use this issue to ask a followup question,
Highway is currently support for z14, z15 and power8 up to power10.
What happens if a non supported older/newer processor is used, i.e z13 or z16. Does it fall back to a generic method or it fails to compile? Do you test this scenario in your CI?Sure :) The fallback code is the generic
HWY_EMU128target which is basically 128-bit with for loops which may or may not autovectorize.
TheHWY_EMU128is indeed covered by CI, but not for POWER. We run POWER-specific tests before releases.@jan-wassenberg Thanks again for confirming.
Reacted by Jan WassenbergSorry to bug you again @jan-wassenberg
This V8 CL is now making use of this library and failing to compile on z13.
We can use-march=z14 -mzvectoras listed under you run_tests.sh for newer z processor but for <= z13 it still compiles in scalar mode due to this line:
Line 398 in fc384ee
#define HWY_BASELINE_Z14 0 The compilation errors we now get include these:
src/hwy/ops/shared-inl.h:368:27 error: static assertion failed: Too many lanes static_assert(kNumLanes <= HWY_LANES(T), "Too many lanes") note: the comparison reduces to '(16 <= 1)' v8/src/json/json-stringifier.cc:2715:33: error: no matching function for call to 'Set(hwy::N_SCALAR::FixedTag<unsigned char, 16>&, int)' const auto mask_0x20 = hw::Set(tag, 0x20);My question is, is this behavior expected and unsupported processors are not able to emulate Simd ops in scalar mode, or are there workarounds available?
Sure, let's have a look.
'Baseline' means always use/generate the instructions, which assumes they are available. Let's clarify the goal: I think we want the fallback (scalar/emu128) to work on z13. This is unrelated to the z14 baseline.
The compile error appears to be user code that assumes exactly 128 bit vectors - that's semi-legit: it's only true if HWY_SCALAR is not being used. What could cause HWY_SCALAR to be used?We have a workaround for compiler breakage:
#if !defined(HWY_BROKEN_EMU128) // allow overriding #if (HWY_COMPILER_GCC_ACTUAL && HWY_COMPILER_GCC_ACTUAL < 1400) || \ defined(HWY_NO_LIBCXX) #define HWY_BROKEN_EMU128 1This causes us to use the deprecated and less-capable HWY_SCALAR, mediated by:
#if defined(HWY_COMPILE_ONLY_SCALAR) || HWY_BROKEN_EMU128 #define HWY_BASELINE_SCALAR HWY_SCALAR #else #define HWY_BASELINE_SCALAR HWY_EMU128 #endifThus one thing we can do is to build with
-DHWY_BROKEN_EMU128=0. Another is to build with a GCC >= 14.0. Hope this helps?Thanks @jan-wassenberg ,
I hard coded
HWY_BROKEN_EMU128=0underhwy/detect_targets.hand it seems to solve the problem, but using the-DHWY_BROKEN_EMU128=0flag during build causes this error:CMake Warning: Manually-specified variables were not used by the project: HWY_BROKEN_EMU128Does
CMakeLists.txtneed to be updated?Reacted by Jan WassenbergSorry to be unclear, that is an option to the C++ compiler, not CMake.
Thank you for clarifying.
Hello,
I'm part of the IBM/Red Hat team that maintains Chromium V8 engine on IBM platforms (ppc64 and s390x).
This library was recently added as a dependency to V8: https://chromium-review.googlesource.com/c/v8/v8/+/6088911
I currently have two questions;
How are the s390x/ppc64 machine specific code maintained under
ops/ppc_vsx-inl.h? is this maintained and tested by google or the community? or is it copied from another source? We also support AIX (big endian ppc64) and need to figure out how we can add support for it if needed.We are currently getting a compilation failure here:
highway/hwy/targets.cc
Line 39 in 83b81ab
asm/hwcap.h. Do we need this header available and if so how should it be installed?AT_HWCAPis defined underlinux/auxvec.hwhich is used bygetauxvalso not sure whyasm/hwcap.his needed in which case it should be safe to set TOOLCHAIN_MISS_ASM_HWCAP_H on ppc64 and 390x.