This reverts commit e907456b2e10622ccd854a3bba8d02ce170b5dbb.
This is due to a CI failure (technically broken HTML with duplicate IDs)
caused by this commit (visibly fine but invalid per the HTML specification
and detected by the LinkCheck tool on the Rust CI process).
The author independently working on a rustdoc enhancement to enable writing
multiple references to a single footnote. Once that change makes it to the
stage0 compiler (the next beta), the original change will be acceptable
again (postponed for possibly the version 1.89 cycle).
Since there's no architectural feature detection on RISC-V (unlike `CPUID`
on x86 architectures and some system registers on Arm/AArch64), runtime
feature detection entirely depends on the platform-specific facility.
As a result, availability of each feature heavily depends on the platform
and its version.
To help users make a decision for feature checking on a RISC-V system, this
commit adds a platform guide with minimum supported platform versions.
Note:
It intentionally omits the description of the reverse implication related
to *extension groups* (such like implication of `B` *from* its members:
`Zba`, `Zbb` and `Zbs` extensions) because it currently does not synchronize
well with the `-Ctarget-feature` compiler option (due to missing reverse
implication checks using `cfg` and due to constraints of the current Rust's
feature handling).
Instead, it only describes forward implications (like `D` implying `F`) due
to the fact that it relatively synchronizes well between Rust and `stdarch`
for this kind of feature handling (not fully synchronized though).
Still, an extension group is considered "supported" once the
platform/version supports runtime detection of all members in it.
- Disable `vsx` tests for `ppc` and `ppc64`
- Disable `tme` tests for `aarch64` and `aarch64_be`
- Disable `frecipe` tests for `loongarch64`
- Add `altivec` run for PPC32 (with `-C target-feature=+vsx` `qemu` gives a nasty error)
Because the current lowest requirements to run the Linux kernel on RISC-V is
RV{32,64}IMA (with 32 general purpose registers) plus some features,
RV32E (with only 16 GPRs) is not currently supported.
Since it's not sure whether current implemented method will work for future
Linux versions even if the minimum requirements are lowered, the support for
RV32E (to be more specific, an attempt to do that) is removed for now.
Until in-kernel feature detection is implemented, runtime detection of
privileged extensions is temporally removed along with features themselves
since none of such privileged features are stable.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
Co-Authored-By: Amanieu d'Antras <amanieu@gmail.com>
This commit implements `riscv_hwprobe`-based feature detection as available
on newer versions of the Linux kernel. It also queries whether the vector
extensions are enabled using `prctl` but this is not supported on QEMU's
userland emulator (as of version 9.2.3) and use the auxiliary vector
as a fallback.
Currently, all extensions discoverable from the Linux kernel version 6.14
and related extension groups (except "Supm", which reports the existence of
`prctl`-based pointer masking control and too OS-dependent) are implemented.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
This commit adds the OS-independent extension implication logic for RISC-V.
It implements:
1. Regular implication (A → B)
a. "the extension A implies the extension B"
b. "the extension A requires the extension B"
c. "the extension A depends on the extension B"
2. Extension group or shorthand (A == B1 & B2...)
a. "the extension A is shorthand for other extensions: B1, B2..."
b. "the extension A comprises instructions provided by B1, B2..."
This is implemented as (A → B1 & B2... + B1 & B2... → A)
where the former is a regular implication as required by specifications
and the latter is a "reverse" implication to improve usability.
and prepares for:
3. Implication with multiple requirements (A1 & A2... → B)
a. "A1 + A2 implies B"
b. (implicitly used to implement reverse implication of case 2)
Although it uses macros and iterators, good optimizers turn the series of
implications into fast bit-manipulation operations.
In the case 2 (extension group or shorthand; where a superset extension
is just a collection of other subextensions and provides no features by
a superset itself), specifications do specify that an extension group
implies its members but not vice versa. However, implying an extension
group from its members would improve usability on the feature detection
(especially when the feature provider does not provide existence of such
extension group but provides existence of its members).
Similar "reverse implication" on RISC-V is implemented on LLVM.
Case 3 is implicitly used to implement reverse implication of case 2 but
there's another use case: implication with multiple requirements like
"Zcf" and "Zcd" extensions (not yet implemented in this crate for now).
To handle extension groups perfectly, we need to loop implication several
times (until they converge; normally 2 times and up to 4 times when we add
most of `riscv_hwprobe`-based features).
To make implementation of that loop possible, `cache::Initializer` is
modified to implement `PartialEq` and `Eq`.
This is ported from Taiki Endo's branch and sorted by the `@FEATURE` order
as in `src/detect/arch/riscv.rs`.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
The "B" extension is once abandoned (instead, it is ratified as a collection
of "Zb*" extensions). However, it is later redefined and ratified as a
superset of "Zba", "Zbb" and "Zbs" extensions (but not "Zbc" carry-less
multiplication for limited benefits and implementation cost).
Although non-functional (because feature detection is not yet implemented),
it provides the foundation to implement this extension (along with
straightforward documentation showing subsets of "B").
The "A" extension comprises instructions provided by the "Zaamo" and
"Zalrsc" extensions. To prepare for the "Zacas" extension (which provides
compare-and-swap instructions and discoverable from Linux) which depends on
the "Zaamo" extension, it would be better to support those subsets.
This commit prepares common infrastructure for extension implication by
removing `enable_features` closure which makes each feature test longer
(because it needs extra `value` argument each time we test a feature).
It comes with the overhead to enable each feature separately but later
mitigated by the OS-independent extension implication logic.
