Skip to content

Support of PPC64 and S390x #2406

Description

@miladfarca

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:

    #include <asm/hwcap.h>
    as we don't have asm/hwcap.h. Do we need this header available and if so how should it be installed? AT_HWCAP is defined under linux/auxvec.h which is used by getauxval so not sure why asm/hwcap.h is needed in which case it should be safe to set TOOLCHAIN_MISS_ASM_HWCAP_H on ppc64 and 390x.

Activity

  1. miladfarca commented on Dec 12, 2024

    @miladfarca
    ContributorAuthor
  2. johnplatts commented on Dec 12, 2024

    @johnplatts
    Contributor
    • 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.

  3. jan-wassenberg commented on Dec 12, 2024

    @jan-wassenberg
    Member

    Hi @miladfarca ,
    The asm/hwcap.h is a workaround for some systems. Yes, it is safe to set TOOLCHAIN_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.

  4. miladfarca commented on Dec 12, 2024

    @miladfarca
    ContributorAuthor

    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.

  5. added a commit that references this issue on Dec 13, 2024
  6. miladfarca commented on Jan 14, 2025

    @miladfarca
    ContributorAuthor

    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?

  7. jan-wassenberg commented on Jan 14, 2025

    @jan-wassenberg
    Member

    Sure :) The fallback code is the generic HWY_EMU128 target which is basically 128-bit with for loops which may or may not autovectorize.
    The HWY_EMU128 is indeed covered by CI, but not for POWER. We run POWER-specific tests before releases.

  8. miladfarca commented on Jan 14, 2025

    @miladfarca
    ContributorAuthor

    @jan-wassenberg Thanks again for confirming.

  9. miladfarca commented on Jan 21, 2025

    @miladfarca
    ContributorAuthor

    Sorry 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 -mzvector as listed under you run_tests.sh for newer z processor but for <= z13 it still compiles in scalar mode due to this line:

    #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?

  10. jan-wassenberg commented on Jan 21, 2025

    @jan-wassenberg
    Member

    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 1
    

    This 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
    #endif
    

    Thus 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?

  11. miladfarca commented on Jan 21, 2025

    @miladfarca
    ContributorAuthor

    Thanks @jan-wassenberg ,

    I hard coded HWY_BROKEN_EMU128=0 under hwy/detect_targets.h and it seems to solve the problem, but using the -DHWY_BROKEN_EMU128=0 flag during build causes this error:

    CMake Warning:
      Manually-specified variables were not used by the project:
    
        HWY_BROKEN_EMU128
    

    Does CMakeLists.txt need to be updated?

  12. jan-wassenberg commented on Jan 21, 2025

    @jan-wassenberg
    Member

    Sorry to be unclear, that is an option to the C++ compiler, not CMake.

  13. miladfarca commented on Jan 21, 2025

    @miladfarca
    ContributorAuthor

    Thank you for clarifying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions