lavu/riscv: do not fallback to AT_HWCAP auxillary vector

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.

RDRémi Denis-Courmont committed 2 years ago