PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built

PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built verification of these facts after lowering to
machine instructions. We also added "memory types" describing layout
of memory and a "checked" flag on memory operations such that we could
verify that any checked memory operation accessed valid memory (as
defined by memory types attached to pointer values via
facts). Wasmtime's Cranelift backend then put appropriate memory types
and facts in its IR such that all accesses to memory (aspirationally)
could be checked, taking the whole mid-end and lowering backend of
Cranelift out of the trusted core that enforces SFI.

This basically worked, at the time, for static memories; but never for
dynamic memories, and then work on the feature lost
prioritization (aka I had to work on other things) and I wasn't able
to complete it and put it in fuzzing/enable it as a production option.

Unfortunately since then it has bit-rotted significantly -- as we add
new backend optimizations and instruction lowerings we haven't kept
the PCC framework up to date.

Inspired by the discussion in #12497 I think it's time to delete
it (hopefully just "for now"?) unless/until we can build it again. And
when we do that, we should probably get it to the point of validating
robust operation on all combinations of memory configurations before
merging. (That implies a big experiment branch rather than a bunch of
eager PRs in-tree, but so it goes.) I still believe it is possible to
build this (and I have ideas on how to do it!) but not right now.

show more ...

Cranelift: update ValueDataPacked to support full Value range. (#12613)

This updates the `ValueDataPacked` scheme from the old

```
(enum tag) (CLIF type) (value 1) (value 2)
/

Cranelift: update ValueDataPacked to support full Value range. (#12613)

This updates the `ValueDataPacked` scheme from the old

```
(enum tag) (CLIF type) (value 1) (value 2)
/// | tag:2 | type:14 | x:24 | y:24
```

encoding in a `u64` to a new

```
/// | tag:2 | type:14 | x:32 | y:32
```

encoding, with a `packed` tag attribute to ensure the struct fits in
10 bytes. This permits the full range of `Value` (a `u32` entity
index) to be encoded, removing the remaining major limit on function
body size after the work in #12611 to address #12229.

Curiously, this appears to be a *speedup* in compile time of 3-5% on
bz2 and 3% on spidermonkey-json (Sightglass, 50 data points each). My
best guess as to why is that putting the value fields in their own
`u32`s allows for quick access without shifts/masks, which is actually
better than the unaligned accesses (caused by 10-byte size) -- which
have no penalty on modern mainstream CPUs -- and 25% size inflation of
the value-definitions array.

show more ...

Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)

* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation

This commit plumbs together two pieces o

Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)

* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation

This commit plumbs together two pieces of recently-added infrastructure:

1. function inlining in Cranelift, and
2. the parallel bottom-up inlining scheduler in Wasmtime.

Sprinkle some very simple inlining heuristics on top, and this gives us function
inlining in Wasm compilation.

The default Wasmtime configuration does not enable inlining, and when we do
enable it, we only enable it for cross-component calls by default (since
presumably the toolchain that produced a particular core Wasm module, like LLVM,
already performed any inlining that was beneficial within that module, but that
toolchain couldn't know how that Wasm module would be getting linked together
with other modules via component composition, and so it could not have done any
cross-component inlining). For what it is worth, there is a config knob to
enable intra-module function inlining, but this is primarily for use by our
fuzzers, so that they can easily excercise and explore this new inlining
functionality.

All this plumbing required some changes to the `wasmtime_environ::Compiler`
trait, since Winch cannot do inlining but Cranelift can. This is mostly
encapsulated in the new `wasmtime_environ::InliningCompiler` trait, for the most
part. Additionally, we take care not to construct the call graph, or any other
data structures required only by the inliner and not regular compilation, both
when using Winch and when using Cranelift with inlining disabled.

Finally, we add a `disas` test to verify that we successfully inline a series of
calls from a function in one component, to a cross-component adapter function,
to a function in another component. Most test coverage is expected to come from
our fuzzing, however.

* Fix dead code warning when not `cfg(feature = "component-model")`

* fix winch trampoline compilation

* Move CLI options to codegen

* Move parameters into struct

* Use an index set for call-graph construction

* Smuggle inlining heuristic options through cranelift flags

* Remove old CLI flags

* set tunables before settings

* Only configure inlining options for cranelift in fuzzing

show more ...

Cranelift: support dynamic contexts in exception-handler lists. (#11321)

In #11285, we realized that Wasm semantics require us to match on
dynamic instances of exception tags, rather than static tag

Cranelift: support dynamic contexts in exception-handler lists. (#11321)

In #11285, we realized that Wasm semantics require us to match on
dynamic instances of exception tags, rather than static tag types. This
fundamentally requires the unwinder to be able to resolve the current
Wasm instance for each Wasm frame on the stack that has any handlers,
and our frame format does not provide this today.

We discussed many options, some of which solve the more general problem
(Wasm vmctx for any frame), but ultimately landed on a notion of
"dynamic context for evaluating tags", specific to Cranelift's
exception-catch metadata; and storing that context and carrying it
through to a place that is named in the unwind metadata. The reasoning
is fairly straightforward: we cannot afford a more general approach that
stores vmctx in every frame (I measured this at 20% overhead for a
recursive-Fibonacci benchmark that is call-intensive); and inlining
means that we may have *multiple* contexts at any given program point,
each associated with a different slice of the handler tags; so we need a
mechanism that, *just for a try-call*, intersperses contexts with tags
(or puts a context on each tag) and stores these somewhere that the
exception-unwind ABI doesn't clobber (e.g., on the stack).

This PR implements "option 4" from that issue, namely, *dynamic
exception contexts*. The idea is that this is the dual to exception
payload: while payload lets the unwinder communicate state *to* the
catching code, context lets the unwinder take state *from* the catching
code that lets it decide whether the tag is a match. Because of
inlining, we need to either associate (optional) context with every tag,
or intersperse context-updates with handler tags. I've opted for the
latter for efficiency at the CLIF level (in most cases there will be
multiple tags per context), though they are isomorphic.

The new tag-matching semantics are: when walking up the stack, upon
reaching a `try_call`, evaluate catch-clauses in listed order. A
`context` clause sets the current context. A `tagN: block(...)` clause
attempts to match the throwing exception against `tagN`, *evaluated in
the current context*, and branches to the named block if it matches. A
`default: block(...)` always branches to the named block.

Note that this lets us assume less about tags than before, and this
particularly manifests in the changes to the inliner. Whereas before,
`tagN` is `tagN` and an inner handler for that tag shadows an outer
handler (that is, tags always alias if identical indices); and whereas
before, `tagN` is not `tagM` and so we can order the tags arbitrarily
(that is, tags never alias if non-identical indices); now any two static
tag indices may or may not alias depending on the dynamic context of
each. Or, even in the same context, two may alias, because we leave the
match-predicate as an unspecified (user-chosen) algorithm during
unwinding. (This mirrors the reality that, for example, a Wasm instance
may import two tags, and dynamically these tags may be equal or
different at runtime, even instantiation-to-instantiation.) Cranelift's
only job is to faithfully carry the list of contexts and tags through to
the compiled-code metadata; and to ensure that they remain in the order
they were specified in the CLIF.

This PR introduces the Cranelift-level feature, and it will be used in
a subsequent PR that introduces Wasm exception handling. Because of
that, I've opted not to update the clif-utils runtest "runtime" to read
out contexts and do something with them -- we will have plenty of test
coverage via a bunch of Wasm tests for corner cases such as the above.
This PR does include filetests that show that contexts are carried
through to spillslots and those appear in the metadata.

Fixes #11285.

show more ...

Cranelift: introduce a function inliner (#11210)

* Cranelift: introduce a function inliner

This comit adds "inlining as a library" to Cranelift; it does _not_ provide a
complete, off-the-shelf inli

Cranelift: introduce a function inliner (#11210)

* Cranelift: introduce a function inliner

This comit adds "inlining as a library" to Cranelift; it does _not_ provide a
complete, off-the-shelf inlining solution. Cranelift's compilation context is
per-function and does not encompass the full call graph. It does not know which
functions are hot and which are cold, which have been marked the equivalent of
`#[inline(always)]` versus `#[inline(never)]`, etc... Only the Cranelift user
can understand these aspects of the full compilation pipeline, and these things
can be very different between (say) Wasmtime and `cg_clif`. Therefore, this
infrastructure does not attempt to define hueristics for when inlining a
particular call is likely beneficial. This module only provides hooks for the
Cranelift user to tell Cranelift whether a given call should be inlined or not,
and the mechanics to inline a callee into a particular call site when the user
directs Cranelift to do so.

This commit also creates a new kind of filetest that will always inline calls to
functions that have already been defined in the file. This lets us exercise the
inliner in filetests.

Fixes https://github.com/bytecodealliance/wasmtime/issues/4127

* Address review feedback

* Require callee bodies are pre-legalized

show more ...

Update nightly used in CI (#10957)

A new lint was added to rustc so this updates the nightly used in CI and
then additionally fixes the lints that are firing.

Enable the `useless_conversion` Clippy lint (#10838)

* Enable the `useless_conversion` Clippy lint

We've got lots of types in Wasmtime and convert between them quite a
lot, but often over time conv

Enable the `useless_conversion` Clippy lint (#10838)

* Enable the `useless_conversion` Clippy lint

We've got lots of types in Wasmtime and convert between them quite a
lot, but often over time conversions become unnecessary through
refactorings or similar. This will hopefully enable us to clean up some
conversions as they come up to try to have as few as possible ideally.

* Review comments

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

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 ...

Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)

* Cranelift: initial try_call / try_call_indirect (exception) support.

This PR adds `try_call` and `try_call_indirect`

Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)

* Cranelift: initial try_call / try_call_indirect (exception) support.

This PR adds `try_call` and `try_call_indirect` instructions, and
lowerings on four of five ISAs (x86-64, aarch64, riscv64, pulley; s390x
has its own non-shared ABI code that will need separate work).

It extends CLIF to support these instructions as new kinds of branches,
and extends block-calls to accept `retN` and `exnN` block-call args that
carry the normal return values or exception payloads (respectively) into
the appropriate successor blocks.

It wires up the "normal return path" so that it continues to work.
It updates the ABI so that unwinding is possible without an initial
register state at throw: specifically, as per our RFC, all registers are
clobbered. It also includes metadata in the `MachBuffer` that describes
exception-catch destinations. However, no unwinder exists to interpret
these catch-destinations yet, so they are untested.

* Add try_call_indirect lowering as well.

show more ...

Enable some more 2024 migration lints (#9962)

Most don't produce many warnings except for `rust-2024-incompatible-pat`
which required removal of a number of `ref` and `ref mut` keywords
throughout t

Enable some more 2024 migration lints (#9962)

Most don't produce many warnings except for `rust-2024-incompatible-pat`
which required removal of a number of `ref` and `ref mut` keywords
throughout the workspace.

show more ...

Convert `TrapCode` to a single byte (#9338)

* Convert `TrapCode` to a single byte

This commit refactors the representation of
`cranelift_codegen::ir::TrapCode` to be a single byte. The previous
enu

Convert `TrapCode` to a single byte (#9338)

* Convert `TrapCode` to a single byte

This commit refactors the representation of
`cranelift_codegen::ir::TrapCode` to be a single byte. The previous
enumeration is replaced with an opaque byte-sized structure. Previous
variants that Cranelift uses internally are now associated `const`
values on `TrapCode` itself. For example `TrapCode::IntegerOverflow` is
now `TrapCode::INTEGER_OVERFLOW`. All non-Cranelift traps are now
removed and exclusively live in the `wasmtime-cranelift` crate now.

The representation of a `TrapCode` is now:

* 0 - invalid, used in `MemFlags` for "no trap code"
* 1..256-N - user traps
* 256-N..256 - built-in Cranelift traps (it uses N of these)

This enables embedders to have 255-N trap codes which is more than
enough for Wasmtime for example. Cranelift reserves a few built-in codes
for itself which shouldn't eat too much into the trap space.
Additionally if Cranelift needs to grow a new trap it can do so pretty
easily too.

The overall intent of this commit is to reduce the coupling of Wasmtime
and Cranelift further and generally refactor Wasmtime to use user traps
more often. This additionally shrinks the size of `TrapCode` for storage
in various locations, notably it can now infallibly be represented
inside of a `MemFlags`.

Closes #9310

* Fix some more tests

* Fix more tests

* Fix even more tests

* Review comments

* Fix tests

* Fix rebase conflict

* Update test expectations

show more ...

Update nightly in CI to latest (#9195)

Additionally address some new warnings that are cropping up throughout
the codebase.

Enforce `uninlined_format_args` for the workspace (#9065)

* Enforce `uninlined_format_args` for the workspace

* fix: failing `Monolith Checks` job

* fix: formatting

Cranelift: Add an `is_safepoint` predicate to `Opcode` (#9066)

Enforce `clippy::clone_on_copy` for the workspace (#9025)

* Derive `Copy` for `Val`

* Fix `clippy::clone_on_copy` for the whole repo

* Enforce `clippy::clone_on_copy` for the workspace

* fix some

Enforce `clippy::clone_on_copy` for the workspace (#9025)

* Derive `Copy` for `Val`

* Fix `clippy::clone_on_copy` for the whole repo

* Enforce `clippy::clone_on_copy` for the workspace

* fix some more clippy::clone_on_copy that got missed

show more ...

Cranelift: Allow CLIF frontends to define their own stack maps (#8728)

Tracking GC references and producing stack maps is a significant amount of
complexity in `regalloc2`.

At the same time, GC ref

Cranelift: Allow CLIF frontends to define their own stack maps (#8728)

Tracking GC references and producing stack maps is a significant amount of
complexity in `regalloc2`.

At the same time, GC reference value types are pretty annoying to deal with in
Cranelift itself. We know our `r64` is "actually" just an `i64` pointer, and we
want to do `i64`-y things with it, such as an `iadd` to compute a derived
pointer, but `iadd` only takes integer types and not `r64`s. We investigated
loosening that restriction and it was way too painful given the way that CLIF
type inference and its controlling type vars work. So to compute those derived
pointers, we have to first `bitcast` the `r64` into an `i64`. This is
unfortunate in two ways. First, because of arcane interactions between register
allocation constraints, stack maps, and ABIs this involves inserting unnecessary
register-to-register moves in our generated code which hurts binary size and
performance ever so slightly. Second, and much more seriously, this is a serious
footgun. If a GC reference isn't an `r64` right now, then it will not appear in
stack maps, and failure to record a live GC reference in a stack map means that
the collector could reclaim the object while you are still using it, leading to
use-after-free bugs! Very bad. And the mid-end needs to know
*not* to GVN these bitcasts or else we get similar bugs (see
https://github.com/bytecodealliance/wasmtime/pull/8317).

Overall GC references are a painful situation for us today.

This commit is the introduction of an alternative. (Note, though, that we aren't
quite ready to remove the old stack maps infrastructure just yet.)

Instead of preserving GC references all the way through the whole pipeline and
computing live GC references and inserting spills at safepoints for stack maps
all the way at the end of that pipeline in register allocation, the
CLIF-producing frontend explicitly generates its own stack slots and spills for
safepoints. The only thing the rest of the compiler pipeline needs to know is
the metadata required to produce the stack map for the associated safepoint. We
can completely remove `r32` and `r64` from Cranelift and just use plain `i32`
and `i64` values. Or `f64` if the runtime uses NaN-boxing, which the old stack
maps system did not support at all. Or 32-bit GC references on a 64-bit target,
which was also not supported by the old system. Furthermore, we *cannot* get
miscompiles due to GVN'ing bitcasts that shouldn't be GVN'd because there aren't
any bitcasts hiding GC references from stack maps anymore. And in the case of a
moving GC, we don't need to worry about the mid-end doing illegal code motion
across calls that could have triggered a GC that invalidated the moved GC
reference because frontends will reload their GC references from the stack slots
after the call, and that loaded value simply isn't a candidate for GVN with the
previous version. We don't have to worry about those bugs by construction.

So everything gets a lot easier under this new system.

But this commit doesn't mean we are 100% done and ready to transition to the new
system, so what is actually in here?

* CLIF producers can mark values as needing to be present in a stack map if they
are live across a safepoint in `cranelift-frontend`. This is the
`FunctionBuilder::declare_needs_stack_map` method.

* When we finalize the function we are building, we do a simple, single-pass
liveness analysis to determine the set of GC references that are live at each
safepoint, and then we insert spills to explicit stack slots just before the
safepoint. We intentionally trade away the precision of a fixed-point liveness
analysis for the speed and simplicity of a single-pass implementation.

* We annotate the safepoint with the metadata necessary to construct its
associated stack map. This is the new
`cranelift_codegen::ir::DataFlowGraph::append_user_stack_map_entry` method and
all that stuff.

* These stack map entries are part of the CLIF and can be roundtripped through
printing and parsing CLIF.

* Each stack map entry describes a GC-managed value that is on the stack and how
to locate it: its type, the stack slot it is located within, and the offset
within that stack slot where it resides. Different stack map entries for the
same safepoint may have different types or a different width from the target's
pointer.

Here is what is *not* handled yet, and left for future follow up commits:

* Lowering the stack map entries' locations from symbolic stack slot and offset
pairs to physical stack frame offsets after register allocation.

* Coalescing and aggregating the safepoints and their raw stack map entries into
a compact PC-to-stack-map table during emission.

* Supporting moving GCs. Right now we generate spills into stack slots for live
GC references just before safepoints, but we don't reload the GC references from
the stack upon their next use after the safepoint. This involves rewriting uses
of the old, spilled values which could be a little finicky, but we think we have
a good approach.

* Port Wasmtime over to using this new stack maps system.

* Removing the old stack map system, including `r{32,64}` from Cranelift and GC
reference handling from `regalloc2`. (For the time being, the new system
generally refers to "user stack maps" to disambiguate from the old system where
it might otherwise be confusing.) If we wanted to remove the old system now,
that would require us to also port Wasmtime to the new system now, and we'd end
up with a monolithic PR. Better to do this incrementally and temporarily have
the old and in-progress new system overlap for a short period of time.

Co-authored-by: Trevor Elliott <[email protected]>

show more ...

Fix some typos (#8641)

* occurred

* winch typos

* tests typos

* cli typos

* fuzz typos

* examples typos

* docs typos

* crates/wasmtime typos

* crates/environ typos

* crates/cranelift typos

Fix some typos (#8641)

* occurred

* winch typos

* tests typos

* cli typos

* fuzz typos

* examples typos

* docs typos

* crates/wasmtime typos

* crates/environ typos

* crates/cranelift typos

* crates/test-programs typos

* crates/c-api typos

* crates/cache typos

* crates other typos

* cranelift/codegen/src/isa typos

* cranelift/codegen/src other typos

* cranelift/codegen other typos

* cranelift other typos

* ci js typo

* .github workflows typo

* RELEASES typo

* Fix clang-format documentation line

---------

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

show more ...

cranelift: Minimize ways to manipulate instruction results (#8293)

* cranelift: Minimize ways to manipulate instruction results

In particular, remove support for detaching/attaching/appending
instr

cranelift: Minimize ways to manipulate instruction results (#8293)

* cranelift: Minimize ways to manipulate instruction results

In particular, remove support for detaching/attaching/appending
instruction results.

The AliasAnalysis pass used detach_results, but leaked the detached
ValueList; using clear_results instead is better.

The verifier's `test_printing_contextual_errors` needed to get the
verifier to produce an error containing a pretty-printed instruction,
and did so by appending too many results. Instead, failing to append any
results gets a similar error out of the verifier, without requiring that
we expose the easy-to-misuse append_result method. However, `iconst` is
not a suitable instruction for this version of the test because its
result type is its controlling type, so failing to create any results
caused assertion failures rather than the desired verifier error. I
switched to `f64const` which has a non-polymorphic type.

The DFG's `aliases` test cleared both results of an instruction and then
reattached one of them. Since we have access to DFG internals in these
tests, it's easier to directly manipulate the relevant ValueList than to
use these unsafe methods.

The only other use of attach/append was in `make_inst_results_reusing`
which decided which to use based on whether a particular result was
supposed to reuse an existing value. Inlining both methods there
revealed that they were nearly identical and could have most of their
code factored out.

While I was looking at uses of `DataFlowGraph::results`, I also
simplified replace_with_aliases a little bit.

* Review comments

show more ...

cranelift: Remove unused `old_signatures` field (#8294)

This map has been unused since #3401.

egraph: Resolve all aliases at once (#8240)

* egraph: Resolve all aliases at once

This way we can use the linear-time alias rewriting pass, and then avoid
having to think about value aliases ever a

egraph: Resolve all aliases at once (#8240)

* egraph: Resolve all aliases at once

This way we can use the linear-time alias rewriting pass, and then avoid
having to think about value aliases ever again.

* Resolve aliases in facts and values_labels

When resolving aliases in values_labels, this discards debug info on
values which are replaced by aliases. However, that is equivalent to the
existing behavior in `Lower::get_value_labels`, which resolves value
aliases first and only then looks for attached debug info.

show more ...

cranelift: Add DFG helper for resolving all value aliases (#8238)

And demonstrate its use in bugpoint. That doesn't have much impact on
anything, which I hope makes this easier to review than changi

cranelift: Add DFG helper for resolving all value aliases (#8238)

And demonstrate its use in bugpoint. That doesn't have much impact on
anything, which I hope makes this easier to review than changing more
important things right away.

There are other places we would probably be better off doing a
whole-function rewrite once rather than calling `resolve_aliases` a
bunch of times, such as the disas tests, the egraph pass, and lowering.
I have not changed those in this PR.

show more ...

cranelift: New InstructionData::map_values helper (#8231)

This is like the DataFlowGraph::map_inst_values method, but that method
mutably borrows `self`, so it goes to a fair bit of trouble to drop

cranelift: New InstructionData::map_values helper (#8231)

This is like the DataFlowGraph::map_inst_values method, but that method
mutably borrows `self`, so it goes to a fair bit of trouble to drop its
borrows around callbacks so the mutable borrow can be used in the
callback too.

This new helper only actually needs to borrow two public fields from the
DFG: `value_lists` and `jump_tables`. Therefore it's possible to use
other fields in the callback as long as the compiler can see all the
fields being used in the same scope. That's good enough for everywhere
we were using this pattern, so we can simplify this way.

The case which motivated this change isn't shown here: It isn't possible
to call `dfg.map_inst_values` on every instruction in `dfg.insts`,
because the borrow on `dfg.insts` prevents taking a mutable borrow on
`dfg`. But we can call this new helper in that case.

show more ...

Update some CI dependencies (#7983)

* Update some CI dependencies

* Update to the latest nightly toolchain
* Update mdbook
* Update QEMU for cross-compiled testing
* Update `cargo nextest` for usag

Update some CI dependencies (#7983)

* Update some CI dependencies

* Update to the latest nightly toolchain
* Update mdbook
* Update QEMU for cross-compiled testing
* Update `cargo nextest` for usage with MIRI

prtest:full

* Remove lots of unnecessary imports

* Downgrade qemu as 8.2.1 seems to segfault

* Remove more imports

* Remove unused winch trait method

* Fix warnings about unused trait methods

* More unused imports

* More unused imports

show more ...

Cranelift: Fix union node bitpacking (#7465)

* Cranelift: Fix union node bitpacking

It turns out we have just been taking the newest rewrite's value for a eclass
union and never actually comparing

Cranelift: Fix union node bitpacking (#7465)

* Cranelift: Fix union node bitpacking

It turns out we have just been taking the newest rewrite's value for a eclass
union and never actually comparing costs and taking the value with the minimum
cost. Whoops!

Fixing this made some test expectations fail, which we resolved by tweaking the
cost function to give materializing constants nonzero cost. This way we prefer
`-x` to `0 - x`.

We also made elaboration function break ties between values with the same cost
with the value index. It prefers larger value indices, since the original
value's index will be lower than all of its rewritten values' indices. This
heuristically prefers rewritten values because we hope our rewrites are all
improvements even when the cost function can't show that.

Co-Authored-By: Chris Fallin <[email protected]>
Co-Authored-By: Trevor Elliott <[email protected]>

* Add more information to assertion message

* Fix off-by-one bug in assertion

* Limit number of matches consumed from ISLE

We generally want to clamp down and avoid runaway behavior here.

But there also seems to be some sort of rustc/llvm bug on Rust 1.71 that is
causing iteration to wild here. This commit avoids that bug.

* Update test expectation

* prtest:full

---------

Co-authored-by: Chris Fallin <[email protected]>
Co-authored-by: Trevor Elliott <[email protected]>

show more ...