Cranelift: Generate integer numeric ops and conversions for ISLE in the meta crate (#11065)

* Cranelift: Generate integer numeric ops and conversions for ISLE in the meta crate

This automatically g

Cranelift: Generate integer numeric ops and conversions for ISLE in the meta crate (#11065)

* Cranelift: Generate integer numeric ops and conversions for ISLE in the meta crate

This automatically generates operations and conversions for integer types for
use in ISLE.

Supported types are: `{i,u}{8,16,32,64,128}`

We generate

* Comparisons (eq, ne, lt, lt_eq, gt, gt_eq)
* Arithmetic operations (add, sub, mul, div, neg)
* These each have checked, wrapping, and unwrapping variants
* Bitwise operations (and, or, xor, shifts, counting leading/trailing zeros/ones)
* A variety of predicates (is_zero, is_power_of_two, is_odd, etc...)
* These generate both partial constructors and a handful of extractors
* Conversions
* These come in a variety of flavors: fallible, infallible, truncating,
unwrapping, sign-reinterpretation
* Fallible conversions are also available as an extractor

* Fix copy paste

* Rename `x_reinterpret_as_y` to `x_cast_[un]signed`

* Collapse some fallible conversions in pulley lowering

* Clean up pulley iconst lowering, make sure narrowest `xconst*` instruction is always used

* Avoid an unnecessary truncation in riscv64 lowering

* Use extractor instead of partial constructor in x64 `imm` rule

* Clean up `op mem, imm` x64 lowering rules

* Use `(i64_eq a b)` instead of `(u64_eq (i64_cast_unsigned a) (i64_cast_unsigned b))`

* Rename `<ty>_unwrapping_<op>` to `<ty>_<op>`

show more ...

Cranelift: simplify some side-effectful instructions in ISLE (#10524)

* Cranelift: simplify some side-effectful instructions in ISLE

This commit adds a new top-level ISLE entrypoint specifically fo

Cranelift: simplify some side-effectful instructions in ISLE (#10524)

* Cranelift: simplify some side-effectful instructions in ISLE

This commit adds a new top-level ISLE entrypoint specifically for instructions
in the side-effectful skeleton: `simplify_skeleton`. While these rewrites are
processed during the egraph pass, values from skeleton instructions still do not
get inserted into the egraph. Indeed, `simplify_skeleton` operates
on *instructions* rather than *values* because we do not represent side effects
as values; values do not have side effects in CLIF, instructions do. Therefore,
rather than doing a whole dynamic-programming style extraction of the best
candidate simplification like we do with the egraph, we take an eager and greedy
approach.

Furthermore, `simplify_skeleton` is limited only to skeleton instructions that
do not involve control-flow or terminators right now. This is because changing
the control-flow graph can change whether a use is dominated by a def or not,
and we do not currently have the machinery to track and fix up invalidated
uses. Addressing this is left for future commits.

* fix `MIN / -1` cprop and add negative tests for things simplify_skeleton cannot handle yet

show more ...

Move `assembler.isle` to "untracked inputs" (#10365)

This fixes a minor issue from #10352 where because `assembler.isle` was
written by the build script itself by including it in the "tracked
inputs

Move `assembler.isle` to "untracked inputs" (#10365)

This fixes a minor issue from #10352 where because `assembler.isle` was
written by the build script itself by including it in the "tracked
inputs" it meant that the build script always re-ran, never caching the
output. This commit moves the file to the "untracked inputs" which means
that while it's used by ISLE it won't be passed to Cargo as input since
it's generated in-process. This re-enables `cargo build` not doing
anything after a successful build.

show more ...

meta: move all ISLE-related generated code to `cranelift-codegen-meta` (#10352)

* meta: move all ISLE-related generated code to `cranelift-codegen-meta`

Previously, the new `cranelift-assembler-x64

meta: move all ISLE-related generated code to `cranelift-codegen-meta` (#10352)

* meta: move all ISLE-related generated code to `cranelift-codegen-meta`

Previously, the new `cranelift-assembler-x64` crate would generate the
assembler Rust code, the ISLE integration code, and the ISLE's
accompanying Rust macro all in the same crate. Because these last two
files were generated in the assembler's `OUT_DIR`, they caused issues
for deterministic builds that expect those files in
`cranelift-codegen`'s `OUT_DIR` (see #10348). This change fixes that by
moving all of the assembler's generated integration code, the ISLE
instruction definitions and their accompanying Rust macro, to the
`cranelift-codegen-meta` crate.

This has the added advantage that `cranelift-assembler-x64` now can
focus exclusively on being an assembler and not being concerned with the
ISLE integration, which is substantial.

* Move lint `allow` to problem site

Apparently allowing unused variables for unimplemented parts of fixed
register instructions will not work at the macro scope; this moves the
`allow` to the offending line.

* Remove `rustfmt` of generated assembler code

show more ...

asm: introduce a new x64 assembler (#10110)

* asm: add initial infrastructure for an external assembler

This change adds some initial logic implementing an external assembler
for Cranelift's x64 ba

asm: introduce a new x64 assembler (#10110)

* asm: add initial infrastructure for an external assembler

This change adds some initial logic implementing an external assembler
for Cranelift's x64 backend, as proposed in RFC [#41].

This adds two crates:
- the `cranelift/assembler/meta` crate defines the instructions; to
print out the defined instructions use `cargo run -p
cranelift-assembler-meta`
- the `cranelift/assembler` crate exposes the generated Rust code for
those instructions; to see the path to the generated code use `cargo
run -p cranelift-assembler`

The assembler itself is straight-forward enough (modulo the code
generation, of course); its integration into `cranelift-codegen` is what
is most tricky about this change. Instructions that we will emit in the
new assembler are contained in the `Inst::External` variant. This
unfortunately increases the memory size of `Inst`, but only temporarily
if we end up removing the extra `enum` indirection by adopting the new
assembler wholesale. Another integration point is ISLE: we generate ISLE
definitions and a Rust helper macro to make the external assembler
instructions accessible to ISLE lowering.

This change introduces some duplication: the encoding logic (e.g. for
REX instructions) currently lives both in `cranelift-codegen` and the
new assembler crate. The `Formatter` logic for the assembler `meta`
crate is quite similar to the other `meta` crate. This minimal
duplication felt worth the additional safety provided by the new
assembler.

The `cranelift-assembler` crate is fuzzable (see the `README.md`). It
will generate instructions with randomized operands and compare their
encoding and pretty-printed string to a known-good disassembler,
currently `capstone`. This gives us confidence we previously didn't have
regarding emission. In the future, we may want to think through how to
fuzz (or otherwise check) the integration between `cranelift-codegen`
and this new assembler level.

[#41]: https://github.com/bytecodealliance/rfcs/pull/41

* asm: bless Cranelift file tests

Using the new assembler's pretty-printing results in slightly different
disassembly of compiled CLIF. This is because the assembler matches a
certain configuration of `capstone`, causing the following obvious
differences:

- instructions with only two operands only print two operands; the
original `MInst` instructions separate out the read-write operand into
two separate operands (SSA-like)
- the original instructions have some space padding after the
instruction mnemonic, those from the new assembler do not

This change uses the slightly new style as-is, but this is open for
debate; we can change the configuration of `capstone` that we fuzz
against. My only preferences would be to (1) retain some way to visually
distinguish the new assembler instructions in the disassembly
(temporarily, for debugging) and (2) eventually transition to
pretty-printing instructions in Intel-style (`rw, r`) instead of the
current (`r, rw`).

* ci: skip formatting when `rustfmt` not present

Though it is likely that `rustfmt` is present in a Rust environment,
some CI tasks do not have this tool installed. To handle this case
(plus the chance that other Wasmtime builds are similar), this change
skips formatting with a `stderr` warning when `rustfmt` fails.

* vet: audit `arbtest` for use as a dev-dependency

* ci: make assembler crates publishable

In order to satisfy `ci/publish.rs`, it would appear that we need to use
a version that matches the rest of the Cranelift crates.

* review: use Cargo workspace values

* review: document `Inst`, move `Inst::name`

* review: clarify 'earlier' doc comment

* review: document multi-byte opcodes

* review: document `Rex` builder methods

* review: document encoding rules

* review: clarify 'bits' -> 'width'

* review: clarify confusing legacy prefixes

* review: tweak IA-32e language

* review: expand documentation for format

* review: move feature list closer to enum

* review: add a TODO to remove AT&T operand ordering

* review: move prefix emission to separate lines

* review: add testing note

* review: fix incomplete sentence

* review: rename `MinusRsp` to `NonRspGpr`

* review: add TODO for commented out instructions

* review: add conservative down-conversion to `is_imm*`

* Fuzzing updates for cranelift-assembler-x64 (#10)

* Fuzzing updates for cranelift-assembler-x64

* Ensure fuzzers build on CI
* Move fuzz crate into the main workspace
* Move `fuzz.rs` support code directly into fuzzer
* Move `capstone` dependency into the fuzzer

* Make `arbitrary` an optional dependency

Shuffle around a few things in a few locations for this.

* vet: skip audit for `cranelift-assembler-x64-fuzz`

Co-authored-by: Alex Crichton <[email protected]>

* review: use 32-bit form for 8-bit and 16-bit reg-reg

Cranelift's existing lowering for 8-bit and 16-bit reg-reg `AND` used
the wider version of the instruction--the 32-bit reg-reg `AND`. As
pointed out by @cfallin [here], this was likely due to avoid partial
register stalls. This change keeps that lowering by distinguishing more
precisely between `GprMemImm` that are in register or memory.

[here]: https://github.com/bytecodealliance/wasmtime/pull/10110#discussion_r1939822255

* fix: skip `rustfmt` on generated code in more cases

Apparently `rustfmt` is not found on the `x86_64-unknown-illumos` build.
This change skips the action in this new case.

prtest:full

* fix: feed Cargo the meta crate version

This fixes errors with the `publish.rs` script.

prtest:full

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

Procedurally generate Pulley Cranelift boilerplate (#9760)

* Procedurally generate Pulley Cranelift boilerplate

This commit is an integration of the `for_each_op!` macro (and extended
ops) for Cran

Procedurally generate Pulley Cranelift boilerplate (#9760)

* Procedurally generate Pulley Cranelift boilerplate

This commit is an integration of the `for_each_op!` macro (and extended
ops) for Cranelift. This procedurally generates a few new items for
Cranelift's Pulley backend to use:

* `RawInst` - a raw enumeration of instructions as-is.
* ISLE constructors (e.g. `pulley_*` ctors) - generated for all of the
`RawInst` variants.
* Register allocation methods for `RawInst`
* Pretty printing methods for `RawInst`
* Emission methods for `RawInst`

The `Inst` enum now has a `Raw` variant which contains a `RawInst`. In
this manner the main `Inst` enum can still have pseudo-insts like
`Call`, polymorphic instructions like loads/stores (probably gonna get
refactored in the future though), and slightly different representations
such as `Inst::Trap` having a `TrapCode` and `RawInst::Trap` wouldn't.

The goal of this commit is to lower the amount of effort to quickly add
and experiment with new instructions in Pulley. Ideally it's now just
(a) define them in the pulley macro, (b) implement a direct lowering
rule, and (c) implement it in the interpreter. Ideally no need to
implement anything else inside of Cranelift as everything should be
auto-generated.

Many existing `Inst` variants have been deleted in favor of their
equivalents in `RawInst` now. This undeniably increases the complexity
of the Pulley backend but at least for me I find it well worth it to
have all this boilerplate generated automatically.

* Fill out TODO

* Fix conditional generation of pulley ISLE

show more ...

ISLE: upstream prototype ISLE verifier (Crocus) (#9178)

* Squash of verification changes 2024-08-28

* Cleanup

* fmt

* More cleanup

* clippy

* update example spec

* fmt

* null

* clippy part 1

ISLE: upstream prototype ISLE verifier (Crocus) (#9178)

* Squash of verification changes 2024-08-28

* Cleanup

* fmt

* More cleanup

* clippy

* update example spec

* fmt

* null

* clippy part 1

* clippy fix, null

* clippy part 3

* fmt

* disable veri_engine tests in CI

* clap dependency

* remove strum

* use easy-smt version

* Get `cargo vet/deny` working and passing

Undoes a seeming `cargo update` that was performed previously and then
adds a vet for the new crate added.

* Flag new crates as not published

* Revert "remove strum"

This reverts commit df7b540b51ebf14d45a7b9f9bbedeba018a53e9a.

* itertools

* Review feedback

* Future work comments for encodings

* fmt

* post merge Cargo.lock updates

* authors

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

Cranelift: Add a new backend for emitting Pulley bytecode (#9089)

* Cranelift: Add a new backend for emitting Pulley bytecode

This commit adds two new backends for Cranelift that emits 32- and 64-b

Cranelift: Add a new backend for emitting Pulley bytecode (#9089)

* Cranelift: Add a new backend for emitting Pulley bytecode

This commit adds two new backends for Cranelift that emits 32- and 64-bit Pulley
bytecode. The backends are both actually the same, with a common implementation
living in `cranelift/codegen/src/isa/pulley_shared`. Each backend configures an
ISA flag that determines the pointer size, and lowering inspects this flag's
value when lowering memory accesses.

To avoid multiple ISLE compilation units, and to avoid compiling duplicate
copies of Pulley's generated `MInst`, I couldn't use `MInst` as the `MachInst`
implementation directly. Instead, there is an `InstAndKind` type that is a
newtype over the generated `MInst` but which also carries a phantom type
parameter that implements the `PulleyTargetKind` trait. There are two
implementations of this trait, a 32- and 64-bit version. This is necessary
because there are various static trait methods for the mach backend which we
must implement, and which return the pointer width, but don't have access to any
`self`. Therefore, we are forced to monomorphize some amount of code. This type
parameter is fairly infectious, and all the "big" backend
types (`PulleyBackend<P>`, `PulleyABICallSite<P>`, etc...) are parameterized
over it. Nonetheless, not everything is parameterized over a `PulleyTargetKind`,
and we manage to avoid duplicate `MInst` definitions and lowering code.

Note that many methods are still stubbed out with `todo!`s. It is expected that
we will fill in those implementations as the work on Pulley progresses.

* Trust the `pulley-interpreter` crate, as it is part of our workspace

* fix some clippy warnings

* Fix a dead-code warning from inside generated code

* Use a helper for emitting br_if+comparison instructions

* Add a helper for converting `Reg` to `pulley_interpreter::XReg`

* Add version to pulley workspace dependency

* search the pulley directory for crates in the publish script

show more ...

move get_isle_compilations to codegen::meta (#8423)