Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our fl

Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our flags to pass
`-Dwarnings` to ensure that we have warning-free doc builds when all
features are enabled at least.

There were quite a lot of preexisting issues to fix, so this
additionally goes through and fixes all the warnings that cropped up.

* Update nightly toolchain again

prtest:full

* Update another nightly

* Fix a warning in generated code

show more ...

cranelift-assembler-x64: no_std support (#12235)

* cranelift-assembler-x64: no_std support

* cargo fmt

* Update cranelift/assembler-x64/src/xmm.rs

Co-authored-by: bjorn3 <[email protected]

cranelift-assembler-x64: no_std support (#12235)

* cranelift-assembler-x64: no_std support

* cargo fmt

* Update cranelift/assembler-x64/src/xmm.rs

Co-authored-by: bjorn3 <[email protected]>

* Update cranelift/assembler-x64/src/imm.rs

Co-authored-by: bjorn3 <[email protected]>

* Update cranelift/assembler-x64/src/api.rs

Co-authored-by: bjorn3 <[email protected]>

* Reorder import of alloc

* #![no_std]

* revert main.rs

* cargo fmt

* remove core feature

* Fix CI

---------

Co-authored-by: bjorn3 <[email protected]>

show more ...

x64: handle ISA features more completely (#11272)

* asm: generate boolean terms of CPU features

As discussed [here], we will soon need the ability to express more
complex combinations of CPU featur

x64: handle ISA features more completely (#11272)

* asm: generate boolean terms of CPU features

As discussed [here], we will soon need the ability to express more
complex combinations of CPU features. These are best expressed as
boolean terms: e.g., `(32-bit OR 64-bit) AND ...`, `(32-bit OR 64-bit)
AND ((AVX512VL AND AVX512F) OR AVX10.1)`. This change modifies the
generated code to have a `Inst::is_available` method which contains a
Rust-ified version of the instruction's boolean term. To do this, we now
pass in a `Features` trait, which the instruction can query to see if
its desired feature set is available.

[here]: https://bytecodealliance.zulipchat.com/#narrow/channel/217117-cranelift/topic/boolean.20terms.20for.20x64.20features

* x64: wire up `Inst::is_available` in Cranelift

This change makes us of the assembler's new generated
`Inst::is_available` methods to check an instruction's feature set in a
more succinct (and likely quicker) way. Unfortunately, this does not
allow us to print the missing ISA requirements on failure--something to
address later.

* Rename `Features` to `AvailableFeatures`

* Remove unused `InstructionSet`

* asm: fix all feature definitions

This is a mechanical transformation converting all instruction
definitions. Now, instructions should have a correct boolean term
describe the features required: e.g., `(_64b | compat) & avx`.

* x64: replace `use_*` with `has_*` when checking ISA features

In Cranelift, the `has_*` flags of `isa::x64::settings::Flags` indicate
that the CPU _has_ some capability; the `use_*` flags indicate that
Cranelift _should emit_ instructions using those capabilities. Further,
the `use_*` flags may turned on by the presence of more than one `has_*`
flags; e.g., when `has_avx` and `has_avx2` are available, `use_avx2` is
enabled.

Now that Cranelift's new x64 assembler understands boolean terms, we no
longer need the `use_*` flags for checking if an instruction can be
emitted: instead, we should use the `has_*` flags and rely on the logic
encoded in `Inst::is_available`.

* asm: materialize `Features` via `Inst::features`

For better error messages (and just for general use of CPU features, see
discussion [here]), this change adds `Inst::features`--a way to
explicitly examine the boolean term for an instruction. This function
returns a `&'static Features` that contains the `AND` and `OR` branches
defining when an instruction is available. This is all generated into
something that looks like:

```rust
pub fn features(&self) -> &'static Features {
const F1: &'static Features = &Features::Feature(Feature::_64b);
const F2: &'static Features = &Features::Feature(Feature::compat);
const F0: &'static Features = &Features::Or(F1, F2);
F0
}
```

This change makes use of `for_each_feature` more: we build up the
`AvailableFeatures` trait and the `Feature` enum from it. This should be
a bit more direct than searching through the generated code (?).

[here]: https://github.com/bytecodealliance/wasmtime/pull/11272#discussion_r2214465871

show more ...

x64: Migrate EVEX instructions to the new assembler (#11303)

* x64: Migrate vpabsq to the new assembler

* x64: Migrate vpopcntb to new assembler

* x64: Migrate vpmullq to the new assembler

* x64:

x64: Migrate EVEX instructions to the new assembler (#11303)

* x64: Migrate vpabsq to the new assembler

* x64: Migrate vpopcntb to new assembler

* x64: Migrate vpmullq to the new assembler

* x64: Migrate vcvtudq2ps to the new assembler

* x64: Migrate vpermi2b to new assembler

* Fix test warnings

show more ...

x64: Add EVEX shifts to the new assembler (#11270)

* x64: Add EVEX shifts to the new assembler

This commit adds bindings for the EVEX encodings of `vps{ll,ra,rl}{d,q}`
to the new assembler. Current

x64: Add EVEX shifts to the new assembler (#11270)

* x64: Add EVEX shifts to the new assembler

This commit adds bindings for the EVEX encodings of `vps{ll,ra,rl}{d,q}`
to the new assembler. Currently the 16-bit shifts `vps{ll,ra,rl}w` are
omitted due to the `avx512bw` feature not yet being bound in Cranelift.
In implementing these instructions a few refactorings/fixes were
necessary:

* Primarily all EVEX instructions now need to be defined not only with
their vector length but also their "tuple type" found in encoding
tables. This is required to correctly handle the 8-bit displacement
scaling that happens with EVEX instructions.
* Some small helpers to the `Evex` structure were added such as
`Evex::digit` and `Evex::ib`.
* The `evex_scaling` factor is now calculated in `generate_evex_prefix`
according to the instruction format itself.
* The VEX and EVEX `generate_*_prefix` functions now delegate to a
shared function to handle the same operand formats across both of
them.
* Fuzz generation of `AmodeOffset` is now updated to bias to some
"interesting" offsets that exercise the cases where EVEX scaling is
necessary.
* The ISLE `XmmUnaryRmRImmEvex` instruction format was removed as it's
no longer necessary.

* Fix emit tests

show more ...

x64: EVEX Encoding for new assembler (#11153)

* evex prefix for new assembler, vaddpd inst, prtest:full

* review: refactor `VexLength` and `EvexLength` into a single `Length`

* review: fix order o

x64: EVEX Encoding for new assembler (#11153)

* evex prefix for new assembler, vaddpd inst, prtest:full

* review: refactor `VexLength` and `EvexLength` into a single `Length`

* review: fix order of instruction definition to match manual

Also, adds some missing `.r()` helpers for consistency.

* review: remove opmask registers and mask kind for now

This will require more work to expose these as special,
runtime-available flags on the generated instruction.

* review: remove as-yet unknown operand patterns for EVEX

It's likely they will share logic with the VEX patterns but we can
refactor that in the future.

* review: fix up the `mmm` bit field, document

* fix: use new `Length` name in doc tests

* review: rename `VexW` to `WBit`

* Ensure VEX instructions cannot be defined with `Length::L512`

* Use `WBit` in REX instructions

---------

Co-authored-by: Andrew Brown <[email protected]>

show more ...