4 ms·

A problem for RISC-V is going to be that there's currently no way for user code to detect the presence of RVV. I have no idea how you can do multiversioning wit

A problem for RISC-V is going to be that there's currently no way for user code to detect the presence of RVV. I have no idea how you can do multiversioning with that limitation.

hmry 2y ago
The solution is to ask the OS to detect it for you. Linux offers a syscall for this (riscv_hwprobe). Has the drawback that it requires OS support, of course. But RVV requires OS support anyway (e.g. managing mstatus, saving vector registers on context switch), so that seems fine to me.
- dzaima 2y ago
  There is some work on an OS-agnostic feature detection C API: https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#extension-bitmask https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/s.... Still quite new though, and potentially might change (as it did a month ago).
- janwas 2y ago
  Or also getauxval? Highway has code to check for this, including that vectors are at least 128 bits: https://github.com/google/highway/blob/master/hwy/targets.cc#L664 https://github.com/google/highway/blob/master/hwy/targets.cc...
thomashabets2 2y ago
Oh? Isn't that what this does? std::arch::is_riscv_feature_detected!("v") Hmm… now that I actually experiment with it, I can't get it to return `true` on hardware that does support it, unless I also compile with -Ctarget-feature=+v. And if I do, then the binary crashes with SIGILL before getting to that point on hardware without rvv. So if it's always equal to cfg!(target_feature="v"), then what does that even mean? I have created https://github.com/rust-lang/rust/issues/139139 https://github.com/rust-lang/rust/issues/139139
fulafel 2y ago
What happens there when you try to execute a missing RVV instruction ? On other archs you get a SIGILL which you can handle.
- dzaima 2y ago
  With RISC-V being an open ISA a vendor can freely add some non-RVV thing on the instruction space used by RVV if it doesn't desire to support RVV. And that already exists with Xtheadvector (aka RVV 0.7.1) where thead made hardware with pre-ratification RVV that's rather incompatible with the ratified RVV1.0 but still uses generally the same encoding space.
- IshKebab 2y ago
  It's "reserved" which is basically the same as C's UB - anything can happen (nasal dragons etc.) so you can't rely on it.
  - bigstrat2003 2y ago
    Just because it's reserved doesn't mean anything can happen. On x86_64, you get a clearly defined error when you use reserved bits and the like. I don't know if RISC-V is the same, but if it isn't it's because they chose to be vague, not because that's what it means to be reserved.
    - dzaima 2y ago
      For what it's worth, the RISC-V unprivileged spec says: > The behavior upon decoding a reserved instruction is UNSPECIFIED. > Some platforms may require that opcodes reserved for standard use raise an illegal-instruction exception. Other platforms may permit reserved opcode space be used for non-conforming extensions. The RVA23 says: (https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc https://github.com/riscv/riscv-profiles/blob/main/src/rva23-...) > Implementations are strongly recommended to raise illegal-instruction exceptions when attempting to execute unimplemented opcodes or access unimplemented CSRs. and has an optional extension "Ssstrict": > Ssstrict No non-conforming extensions are present. Attempts to execute unimplemented opcodes or access unimplemented CSRs in the standard or reserved encoding spaces raises an illegal instruction exception that results in a contained trap to the supervisor-mode trap handler.
quesomaster9000 2y ago
It's a shame that the `MISA` CSR is in the 'Privileged Architecture' spec, otherwise you could just check bit 21 for 'V', but that appears to only be available in the highest privilege machine-mode. Presumably your OS could trap attempts to read the CSR and allow it, but if not then it's a fatal error and your program shits the bed, otherwise you rely on some OS-specific way of getting that info at runtime.

A problem for RISC-V is going to be that there's currently no way for user code to detect the presence of RVV. I have no idea how you can do multiversioning with that limitation.

hmry 2y ago

The solution is to ask the OS to detect it for you. Linux offers a syscall for this (riscv_hwprobe). Has the drawback that it requires OS support, of course. But RVV requires OS support anyway (e.g. managing mstatus, saving vector registers on context switch), so that seems fine to me.

dzaima 2y ago
There is some work on an OS-agnostic feature detection C API: https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#extension-bitmask https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/s.... Still quite new though, and potentially might change (as it did a month ago).
janwas 2y ago
Or also getauxval? Highway has code to check for this, including that vectors are at least 128 bits: https://github.com/google/highway/blob/master/hwy/targets.cc#L664 https://github.com/google/highway/blob/master/hwy/targets.cc...

thomashabets2 2y ago

Oh? Isn't that what this does? std::arch::is_riscv_feature_detected!("v") Hmm… now that I actually experiment with it, I can't get it to return `true` on hardware that does support it, unless I also compile with -Ctarget-feature=+v. And if I do, then the binary crashes with SIGILL before getting to that point on hardware without rvv. So if it's always equal to cfg!(target_feature="v"), then what does that even mean? I have created https://github.com/rust-lang/rust/issues/139139 https://github.com/rust-lang/rust/issues/139139

fulafel 2y ago

What happens there when you try to execute a missing RVV instruction ? On other archs you get a SIGILL which you can handle.

dzaima 2y ago
With RISC-V being an open ISA a vendor can freely add some non-RVV thing on the instruction space used by RVV if it doesn't desire to support RVV. And that already exists with Xtheadvector (aka RVV 0.7.1) where thead made hardware with pre-ratification RVV that's rather incompatible with the ratified RVV1.0 but still uses generally the same encoding space.
IshKebab 2y ago
It's "reserved" which is basically the same as C's UB - anything can happen (nasal dragons etc.) so you can't rely on it.
- bigstrat2003 2y ago
  Just because it's reserved doesn't mean anything can happen. On x86_64, you get a clearly defined error when you use reserved bits and the like. I don't know if RISC-V is the same, but if it isn't it's because they chose to be vague, not because that's what it means to be reserved.
  - dzaima 2y ago
    For what it's worth, the RISC-V unprivileged spec says: > The behavior upon decoding a reserved instruction is UNSPECIFIED. > Some platforms may require that opcodes reserved for standard use raise an illegal-instruction exception. Other platforms may permit reserved opcode space be used for non-conforming extensions. The RVA23 says: (https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc https://github.com/riscv/riscv-profiles/blob/main/src/rva23-...) > Implementations are strongly recommended to raise illegal-instruction exceptions when attempting to execute unimplemented opcodes or access unimplemented CSRs. and has an optional extension "Ssstrict": > Ssstrict No non-conforming extensions are present. Attempts to execute unimplemented opcodes or access unimplemented CSRs in the standard or reserved encoding spaces raises an illegal instruction exception that results in a contained trap to the supervisor-mode trap handler.

quesomaster9000 2y ago

It's a shame that the `MISA` CSR is in the 'Privileged Architecture' spec, otherwise you could just check bit 21 for 'V', but that appears to only be available in the highest privilege machine-mode. Presumably your OS could trap attempts to read the CSR and allow it, but if not then it's a fatal error and your program shits the bed, otherwise you rely on some OS-specific way of getting that info at runtime.