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

Support referencing stack slots in the DWARF debug info (#6960)

* Add a test

* Disable test

* Add support for specifying stack locations in debug info

Always emit SysV-style CFI unwind info if we

Support referencing stack slots in the DWARF debug info (#6960)

* Add a test

* Disable test

* Add support for specifying stack locations in debug info

Always emit SysV-style CFI unwind info if we need debug info,
and reference it in the debug info using DW_OP_call_frame_cfa.

* Add toolchain comment to the test

* Add a comment and assert

show more ...

Decouple `serde` from its `derive` crate (#6917)

By not activating the `derive` feature on `serde`, the compilation speed
can be improved by a lot. This is because `serde` can then compile in
parall

Decouple `serde` from its `derive` crate (#6917)

By not activating the `derive` feature on `serde`, the compilation speed
can be improved by a lot. This is because `serde` can then compile in
parallel to `serde_derive`, allowing it to finish compilation possibly
even before `serde_derive`, unblocking all the crates waiting for
`serde` to start compiling much sooner.

As it turns out the main deciding factor for how long the compile time of a
project is, is primarly determined by the depth of dependencies rather
than the width. In other words, a crate's compile times aren't affected
by how many crates it depends on, but rather by the longest chain of
dependencies that it needs to wait on. In many cases `serde` is part of
that long chain, as it is part of a long chain if the `derive` feature
is active:

`proc-macro2` compile build script > `proc-macro2` run build script >
`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >
`serde_json` (or any crate that depends on serde)

By decoupling it from `serde_derive`, the chain is shortened and compile
times get much better.

Check this issue for a deeper elaboration:
https://github.com/serde-rs/serde/issues/2584

For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s when
compiling in `release` mode. This is because wasmtime through `gimli`
has a dependency on `indexmap` which can only start compiling when
`serde` is finished, which you want to happen as early as possible so
some of wasmtime's dependencies can start compiling.

To measure the full effect, the dependencies can't by themselves
activate the `derive` feature. I've upstreamed a patch for
`fxprof-processed-profile` which was the only dependency that activated
it for `wasmtime` (not yet published to crates.io). `wasmtime-cli` and
co. may need patches for their dependencies to see a similar
improvement.

show more ...

A bunch of minor cleanups (#6767)

* Remove DisplayFunctionAnnotations

It used to exist for printing the debuginfo value ranges with the clif
ir, but this no longer happens, so it is now useless.

*

A bunch of minor cleanups (#6767)

* Remove DisplayFunctionAnnotations

It used to exist for printing the debuginfo value ranges with the clif
ir, but this no longer happens, so it is now useless.

* Remove debug info collection from DummyEnvironment

There are no remaining users of it

* Remove ComparableSourceLoc

It is unused

* Move LabelValueLoc re-export out of the ir module

It encodes target specific information, so shouldn't be in the target
independent ir module.

* Remove RelocDistance dependency from ir::extfunc and ir::globalvalue

show more ...

Switch Cranelift over to regalloc2. (#3989)

This PR switches Cranelift over to the new register allocator, regalloc2.

See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f6

Switch Cranelift over to regalloc2. (#3989)

This PR switches Cranelift over to the new register allocator, regalloc2.

See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f67301801)
for a summary of the design changes. This switchover has implications for
core VCode/MachInst types and the lowering pass.

Overall, this change brings improvements to both compile time and speed of
generated code (runtime), as reported in #3942:

```
Benchmark Compilation (wallclock) Execution (wallclock)
blake3-scalar 25% faster 28% faster
blake3-simd no diff no diff
meshoptimizer 19% faster 17% faster
pulldown-cmark 17% faster no diff
bz2 15% faster no diff
SpiderMonkey, 21% faster 2% faster
fib(30)
clang.wasm 42% faster N/A
```

show more ...

Remove ancient register allocation (#3401)

Fix build_value_labels_ranges for newBE when there are no labels

Detailed debug-info (DWARF) support in new backends (initially x64).

This PR propagates "value labels" all the way from CLIF to DWARF
metadata on the emitted machine code. The key idea is as follows

Detailed debug-info (DWARF) support in new backends (initially x64).

This PR propagates "value labels" all the way from CLIF to DWARF
metadata on the emitted machine code. The key idea is as follows:

- Translate value-label metadata on the input into "value_label"
pseudo-instructions when lowering into VCode. These
pseudo-instructions take a register as input, denote a value label,
and semantically are like a "move into value label" -- i.e., they
update the current value (as seen by debugging tools) of the given
local. These pseudo-instructions emit no machine code.

- Perform a dataflow analysis *at the machine-code level*, tracking
value-labels that propagate into registers and into [SP+constant]
stack storage. This is a forward dataflow fixpoint analysis where each
storage location can contain a *set* of value labels, and each value
label can reside in a *set* of storage locations. (Meet function is
pairwise intersection by storage location.)

This analysis traces value labels symbolically through loads and
stores and reg-to-reg moves, so it will naturally handle spills and
reloads without knowing anything special about them.

- When this analysis converges, we have, at each machine-code offset, a
mapping from value labels to some number of storage locations; for
each offset for each label, we choose the best location (prefer
registers). Note that we can choose any location, as the symbolic
dataflow analysis is sound and guarantees that the value at the
value_label instruction propagates to all of the named locations.

- Then we can convert this mapping into a format that the DWARF
generation code (wasmtime's debug crate) can use.

This PR also adds the new-backend variant to the gdb tests on CI.

show more ...

Three fixes to various SpiderMonkey-related issues:

- Properly mask constant values down to appropriate width when
generating a constant value directly in aarch64 backend. This was a
miscompilat

Three fixes to various SpiderMonkey-related issues:

- Properly mask constant values down to appropriate width when
generating a constant value directly in aarch64 backend. This was a
miscompilation introduced in the new-isel refactor. In combination
with failure to respect NarrowValueMode, this resulted in a very
subtle bug when an `i32` constant was used in bit-twiddling logic.

- Add support for `iadd_ifcout` in aarch64 backend as used in explicit
heap-check mode. With this change, we no longer fail heap-related
tests with the huge-heap-region mode disabled.

- Remove a panic that was occurring in some tests that are currently
ignored on aarch64, by simply returning empty/default information in
`value_label` functionality rather than touching unimplemented APIs.
This is not a bugfix per-se, but removes confusing panic messages from
`cargo test` output that might otherwise mislead.

show more ...

Fix value label ranges resolution (#1572)

There was a bug how value labels were resolved, which caused some DWARF expressions not be transformed, e.g. those are in the registers.

* Implements

Fix value label ranges resolution (#1572)

There was a bug how value labels were resolved, which caused some DWARF expressions not be transformed, e.g. those are in the registers.

* Implements FIXME in expression.rs
* Move TargetIsa from CompiledExpression structure
* Fix expression format for GDB
* Add tests for parsing
* Proper logic in ValueLabelRangesBuilder::process_label
* Tests for ValueLabelRangesBuilder
* Refactor build_with_locals to return Iterator instead of Vec<_>
* Misc comments and magical numbers

show more ...

Mass rename Ebb and relatives to Block (#1365)

* Manually rename BasicBlock to BlockPredecessor

BasicBlock is a pair of (Ebb, Inst) that is used to represent the
basic block subcomponent of an E

Mass rename Ebb and relatives to Block (#1365)

* Manually rename BasicBlock to BlockPredecessor

BasicBlock is a pair of (Ebb, Inst) that is used to represent the
basic block subcomponent of an Ebb that is a predecessor to an Ebb.

Eventually we will be able to remove this struct, but for now it
makes sense to give it a non-conflicting name so that we can start
to transition Ebb to represent a basic block.

I have not updated any comments that refer to BasicBlock, as
eventually we will remove BlockPredecessor and replace with Block,
which is a basic block, so the comments will become correct.

* Manually rename SSABuilder block types to avoid conflict

SSABuilder has its own Block and BlockData types. These along with
associated identifier will cause conflicts in a later commit, so
they are renamed to be more verbose here.

* Automatically rename 'Ebb' to 'Block' in *.rs

* Automatically rename 'EBB' to 'block' in *.rs

* Automatically rename 'ebb' to 'block' in *.rs

* Automatically rename 'extended basic block' to 'basic block' in *.rs

* Automatically rename 'an basic block' to 'a basic block' in *.rs

* Manually update comment for `Block`

`Block`'s wikipedia article required an update.

* Automatically rename 'an `Block`' to 'a `Block`' in *.rs

* Automatically rename 'extended_basic_block' to 'basic_block' in *.rs

* Automatically rename 'ebb' to 'block' in *.clif

* Manually rename clif constant that contains 'ebb' as substring to avoid conflict

* Automatically rename filecheck uses of 'EBB' to 'BB'

'regex: EBB' -> 'regex: BB'
'$EBB' -> '$BB'

* Automatically rename 'EBB' 'Ebb' to 'block' in *.clif

* Automatically rename 'an block' to 'a block' in *.clif

* Fix broken testcase when function name length increases

Test function names are limited to 16 characters. This causes
the new longer name to be truncated and fail a filecheck test. An
outdated comment was also fixed.

show more ...

Fix clippy warnings.

This commit fixes the current set of (stable) clippy warnings in the repo.

Rustfmt

Always use extern crate std in cranelift-codegen

Use a sorted array for (Ebb, Inst) interval again (fixes #1084);

Allow building without std (#1069)

Closes https://github.com/CraneStation/cranelift/issues/1067

Regalloc: remove the transient LiveRangeContext data structure;

Add EntryRegDiversions to record diversions for each block entry.

Implement serde and equality traits for SecondaryMap

Serialize ValueLabel and StackSlots (#888)

Add the dyn keyword before trait objects;

Export ValueLocRange and DisplayFunctionAnnotations::default()

Reconstruct locations of the original source variable