If __riscv_hwprobe() fails, then the kernel version is presumably too old. There is not much point falling back to the auxillary vector. - The Linux kernel requires I, so the flag is always set on Linux, and run-time detection is unnecessary. Our RISC-V assembler does anyway not support targets without I. - Linux can compile with or without F and D, but it cannot perform run-time detection for them (a kernel with F support will not boot a processor without F). The run-time detection is thus useless in that case. Besides F and D extensions are used throughout the C code, so their run-time detection would not be practical. - Support for V was added in a later kernel version than riscv_hwprobe(), so the system call will always be available if the kernel supports V. The only exception would be vendor kernel forks, but those are known to haphasardly pretend to support V on systems without actual V support, or with only pre-ratification binary-incompatible version. Furthermore, a large chunk of our optimisations require Zba and/or Zbb which cannot be detected with HWCAP in those kernels. For what it is worth, OpenJDK already took a similar action. Note that this keeps AT_HWCAP usage for platforms with neither C run-time <sys/hwprobe.h> nor kernel <asm/hwprobe.h>, notably kernels other than Linux.
Unified · Split
| @@ -83,9 +83,8 @@ int ff_get_cpu_flags_riscv(void) · 82 unmodified lines | ||
| 83 | 83 | break; |
| 84 | 84 | default: |
| 85 | 85 | } |
| 86 | − } else | |
| 87 | −#endif | |
| 88 | −#if HAVE_GETAUXVAL | |
| 86 | + } | |
| 87 | +#elif HAVE_GETAUXVAL | |
| 89 | 88 | { |
| 90 | 89 | const unsigned long hwcap = getauxval(AT_HWCAP); |
| 91 | 90 | |