-march rv64gcv1p0 does not make sense on RVA23 platforms

[xypron]

Ubuntu 25.10 is compiled for rva23u64. This includes many other extensions besides vector that could add up to speed-ups. Therefore it does not make sense to enforce -march rv64gcv1p0 in file BUILD (cf. #1740).

Building with different parts of highway using different settings of -march currently leads to errors in link time optimization (LTO) on GCC 15.2. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812. Unfortunately the GCC patch a7fe8f83bf89 ("RISC-V: Always register vector built-in functions during LTO [PR110812]".

Please, provide a solution to compile all of highway using the default GCC profile.

[xypron]

Linked Ubuntu bug report: 2121375 FTBFS with GCC 15.2.

[jan-wassenberg]

Hi, I agree it's not ideal to hard-code march. Highway supports using target attributes and runtime dispatch, which would avoid this problem.

Unfortunately we are not able to enable it due to compiler bugs/limitations:

// The riscv_vector.h in Clang 16-18 requires compiler flags, and 19 still has
// some missing intrinsics, see
// https://github.com/llvm/llvm-project/issues/56592. GCC 13.3 also has an
// #error check, whereas 14.1 fails with "argument type 'vuint16m8_t' requires
// the V ISA extension": https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115325.
#if HWY_ARCH_RISCV && HWY_COMPILER_CLANG >= 1900 && 0
#define HWY_HAVE_RUNTIME_DISPATCH_RVV 1

Would you like to try enabling that with GCC 15.2 and see if it works there?

[xypron]

Building origin/master natively on a rva23s64 VM using GCC 15.2 with rva23u64 extensions enabled by default succeeded using this diff:

diff --git a/hwy/detect_targets.h b/hwy/detect_targets.h
index 5671253e..58dd7c0d 100644
--- a/hwy/detect_targets.h
+++ b/hwy/detect_targets.h
@@ -757,7 +757,7 @@
 // https://github.com/llvm/llvm-project/issues/56592. GCC 13.3 also has an
 // #error check, whereas 14.1 fails with "argument type 'vuint16m8_t' requires
 // the V ISA extension": https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115325.
-#if HWY_ARCH_RISCV && HWY_COMPILER_CLANG >= 1900 && 0
+#if HWY_ARCH_RISCV && (HWY_COMPILER_CLANG >= 1900 || HWY_COMPILER_GCC >= 1502)
 #define HWY_HAVE_RUNTIME_DISPATCH_RVV 1
 #else
 #define HWY_HAVE_RUNTIME_DISPATCH_RVV 0

[xypron]

Running cmake after above build of (orgin/master a6e149c) yielded:

99% tests passed, 3 tests failed out of 818

Total Test time (real) =  33.75 sec

The following tests FAILED:
	263 - HwyDemoteTestGroup/HwyDemoteTest.TestAllReorderDemote2To/RVV  # GetParam() = 137438953472 (Failed)
	265 - HwyDemoteTestGroup/HwyDemoteTest.TestAllOrderedDemote2To/RVV  # GetParam() = 137438953472 (Failed)
	698 - DotTestGroup/DotTest.TestAllDotF32BF16/RVV  # GetParam() = 137438953472 (Failed)
Errors while running CTest

[jan-wassenberg]

Interesting, thanks for testing. One nit: we want to check HWY_COMPILER_GCC_ACTUAL, because clang also sets HWY_COMPILER_GCC.

Would the now-failing tests (after the patch) previously pass with the same compiler (and without the patch), if you instead change our -march to whatever is required to match your Ubuntu?

[xypron]

@jan-wassenberg

I guess you mean I should change these lines:
meson.build:282: riscv_arg = '-march=rv64gcv1p0'
CMakeLists.txt:523: list(APPEND HWY_FLAGS -march=rv64gcv1p0)
BUILD:113: "-march=rv64gcv1p0",

to

-march=rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_zmmul_za64rs_zaamo_zalrsc_zawrs_zfa_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbs_zkt_zvbb_zve32f_zve32x_zve64d_zve64f_zve64x_zvfhmin_zvkb_zvkt_zvl128b_zvl32b_zvl64b_supm

[jan-wassenberg]

Yes please :) Was thinking just locally, without a pull request, to narrow down whether the test failure is due to the runtime dispatch and/or target pragmas, or something else/pre-existing.

[xypron]

@jan-wassenberg
With the appended diff

hwy/ops/rvv-inl.h:967:33: error: cannot convert ‘vfloat16mf2_t’ to ‘hwy::N_RVV::VFromD<hwy::N_RVV::Simd<hwy::float16_t, 2, -1> >’ {aka ‘__rvv_uint16mf2_t’} in return
  967 |   return detail::BitCastFromByte(d, detail::BitCastToByte(d, v));
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                 |
      |                                 vfloat16mf2_t

highway.diff.txt

[jan-wassenberg]

Thanks! I suspect the following is happening:

HWY_HAVE_FLOAT16 = 0 and HWY_RVV_HAVE_F16C = 1.

If !HWY_HAVE_FLOAT16, VFromD is deduced as u16, the return value of

template <class D, HWY_IF_F16_D(D)>
decltype(Set(RebindToUnsigned<D>(), 0)) Set(D d, hwy::float16_t arg) {

But for BitCast we then define

#elif HWY_RVV_HAVE_F16C  // zvfhmin provides reinterpret* intrinsics:
HWY_RVV_FOREACH_F16_UNCONDITIONAL(HWY_RVV_CAST_IF, _, reinterpret, _ALL)
HWY_RVV_FOREACH_F16_UNCONDITIONAL(HWY_RVV_CAST_VIRT_IF, _, reinterpret, _VIRT)

Those intrinsics return the actual f16 type, but we want u16. Would you like to try removing the latter three lines?

[xypron]

@jan-wassenberg

I removed the three lines starting at #elif and received this error:

hwy/tests/test_util-inl.h:120:18: error: cannot convert ‘vfloat16m1_t’ to ‘hwy::N_RVV::VFromD<hwy::N_RVV::Simd<hwy::float16_t, 1, 0> >’ {aka ‘__rvv_uint16m1_t’} in return
  120 |   return DemoteTo(d, Set(df, static_cast<float>(first)));
      |          ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                  |
      |                  vfloat16m1_t

[xypron]

If you want to test on your own RISC-V VM, a Ubuntu 25.10 image can be downloaded at https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/questing-preinstalled-server-riscv64.img.xz. Instructions for running a VM are available at https://canonical-ubuntu-boards.readthedocs-hosted.com/en/latest/how-to/qemu-riscv/.

[jan-wassenberg]

Thanks, makes sense. I see that a few more changes will be required (where HWY_RVV_HAVE_F16C is mentioned). I will see if I can reproduce this with just zvfhmin.