dev: Cranelift/x64 backend: do not use one-way branches. (#10086)

* Cranelift/x64 backend: do not use one-way branches.

In #9980, we saw that code copmiled with the single-pass register
allocator has incorrect behavior. We eventually narrowed this down to
the fact that the single-pass allocator is inserting code meant to be
at the end of a block, just before its terminator, *between* two
branches that form the terminator sequence. The allocator is correct;
the bug is with Cranelift's x64 backend.

When we produce instructions into a VCode container, we maintain basic
blocks, and we have the invariant (usual for basic block-based IR)
that only the last -- terminator -- instruction is a branch that can
leave the block. Even the conditional branches maintain this
invariant: though VCode is meant to be "almost machine code", we
emit *two-target conditionals* that are semantically like "jcond;
jmp". We then are able to optimize this inline during binary emission
in the `MachBuffer`: the buffer knows about unconditional and
conditional branches and will "chomp" branches off the tail of the
buffer whenever they target the fallthrough block. (We designed the
system this way because it is simpler to think about BBs that are
order-invariant, i.e., not bake the "fallthrough" concept into the
IR.) Thus we have a simpler abstraction but produce optimal terminator
sequences.

Unfortunately, when adding a branch-on-floating-point-compare
lowering, we had the need to branch to a target if either of *two*
conditions were true, and rather than add a new kind of terminator
instruction, we added a "one-armed branch": conditionally branch to
label or fall through. We emitted this in sequence right before the
actual terminator, so semantically it was almost equivalent.

I write "almost" because the register allocator *is* allowed to insert
spills/reloads/moves between any two instructions. Here the distinct
pieces of the terminator sequence matter: the allocator might insert
something just before the last instruction, assuming the basic-block
"single in, single out" invariant means this will always run with the
block. With one-armed branches this is no longer true.

The backtracking allocator (our original RA2 algorithm, and still the
default today) will never insert code at the end of a block when it
has multiple terminators, because it associates such block-start/end
insertions with *edges*; so in such conditions it inserts instructions
into the tops of successor blocks instead. But the single-pass
allocator needs to perform work at the end of every block, so it will
trigger this bug.

This PR removes `JmpIf` and converts the br-of-fcmp lowering to use
`JmpCondOr` instead, which is a pseudoinstruction that does `jcc1;
jcc2; jmp`. This maintains the BB invariant and fixes the bug.

Note that Winch still uses `JmpIf`, so we cannot remove it entirely:
this PR renames it to `WinchJmpIf` instead, and adds a mechanism to
assert failure if it is ever added to `VCode` (rather than emitted
directly, as Winch's macro-assembler does). We could instead write
Winch's `jmp_if` assembler function in terms of `JmpCond` with a
fallthrough label that is immediately bound, and let the MachBuffer
always chomp the jmp; I opted not to regress Winch compiler
performance by doing this. If one day we abstract out the assembler
further, we can remove `WinchJmpIf`.

This is one of two instances of a "one-armed branch"; the other is
s390x's `OneWayCondBr`, used in `br_table` lowerings, which we will
address separately. Once we do, that will address #9980 entirely.

* Add test for cascading branch-chomping behavior.

* keep the paperclip happy

v29.0.1: Release Wasmtime 29.0.1 (#10070)

29.0.1

Released 2025-01-21.

Fixed

• Fix a missing increment in WASIp1-to-WASIp2 adapter which affected WASI
  configurations that have multiple preopened directories.
  #10064

v29.0.0: Release Wasmtime 29.0.0 (#10049)

29.0.0

Released 2025-01-20.

Added

• Winch now supports epoch-based interruption.
  #9737

• Pulley, Wasmtime's WebAssembly interpreter, has seen quite a lot of progress
  and support fleshed out. It's still not 100% complete but should be about
  ready to start kicking the tires.
  #9744

• The Wasmtime CLI now supports a -Wextended-const flag to control whether the
  extended-const wasm proposal is enabled or not.
  #9768

• Work continues to progress on the AArch64 Winch backend, bringing it closer to
  completion.
  #9762
  #9767
  #9751
  #9784
  #9781
  #9792
  #9787
  #9798
  #9850

• Wasmtime now supports a "custom code publisher" which can be useful when
  Wasmtime doesn't have built-in support for a particular environment.
  #9778

• Configuration options have been added for wasmtime-wasi-http outgoing
  bodies.
  #9800

• Log prefixes can now be disabled for the wasmtime serve command.
  #9821

• A new WASMTIME_LOG_NO_CONTEXT environment variable was added to live
  alongside WASMTIME_LOG.
  #9902

• Release artifacts for aarch64-musl targets are now available.
  #9934

Changed

• Wasmtime libcalls now return whether a trap happened rather than raising a
  trap directly to better prepare for the Pulley interpreter and an eventual
  implementation of Wasm exception-handling.
  #9710

• Wasmtime will now use the Pulley interpreter by default on platforms that
  are not supported by Cranelift.
  #9741

• Demangling symbols in profiling and debugging has improved to handle failures
  to demangle C++ symbols.
  #9756

• WASI WIT files have been updated to 0.2.3.
  #9807

• Wasmtime's bindgen! macro in async mode no longer uses #[async_trait]
  an instead natively uses async fn in traits.
  #9867

• Floats are no longer canonicalized flowing into or out of components.
  #9879

• Instance methods are now translated to static methods in DWARF translation.
  #9898

• The C API now supports debug builtins for debugging guest code.
  #9915

Fixed

• The header file for wasmtime_instance_pre_instantiate in the C API has been
  fixed.
  #9770

• WebAssembly DWARF is more conservative in its GC pass during translation to
  native DWARF.
  #9829

• Debugging intrinsics are fixed on Linux to be exported now.
  #9866

v28.0.1: Release Wasmtime 28.0.1 (#10015)

28.0.1

Released 2025-01-14.

Fixed

• Fixed deallocating async stacks when using Store::into_data.
  #10009

v28.0.0: Release Wasmtime 28.0.0 (#9876)

28.0.0

Released 2024-12-20.

Added

• The ISLE DSL used for Cranelift now has a first-class bool type.
  #9593

• Cranelift now supports a new single-pass register allocator designed for
  compile-time performance (unlike the current default which is optimized for
  runtime-of-generated-code performance).
  #9611

• The wasmtime crate now natively supports the wasm-wave crate and its
  encoding of component value types.
  #8872

• A Module can now be created from an already-open file.
  #9571

• A new default-enabled crate feature, signals-based-traps, has been added to
  the wasmtime crate. When disabled then runtime signal handling is not
  required by the host. This is intended to help with future effort to port
  Wasmtime to more platforms.
  #9614

• Linear memories may now be backed by malloc in certain conditions when guard
  pages are disabled, for example.
  #9614
  #9634

• Wasmtime's async feature no longer requires std.
  #9689

• The buffer and budget capacity of OutgoingBody in wasmtime-wasi-http are
  now configurable.
  #9670

Changed

• Wasmtime's external and internal distinction of "static" and "dynamic"
  memories has been refactored and reworded. All options are preserved but
  exported under different names with improved documentation about how they all
  interact with one another. (and everything should be easier to understand)
  #9545

• Each Store<T> now caches a single fiber stack in async mode to avoid
  allocating/deallocating if the store is used multiple times.
  #9604

• Linear memories now have a 32MiB guard region at the end instead of a 2GiB
  guard region by default.
  #9606

• Wasmtime will no longer validate dependencies between WebAssembly features,
  instead delegating this work to wasmparser's validator.
  #9623

• Cranelift's isle-in-source-tree feature has been re-worked as an environment
  variable.
  #9633

• Wasmtime's minimum supported Rust version is now 1.81.
  #9692

• Synthetic types in DWARF are now more efficiently represented.
  #9700

• Debug builtins on Windows are now exported correctly.
  #9706

• Documentation on Config now clarifies that defaults of some options may
  differ depending on the selected target or compiler depending on features
  supported.
  #9705

• Wasmtime's error-related types now all unconditionally implement the Error
  trait, even in #[no_std] mode.
  #9702

Fixed

• Field type matching for subtyping with wasm GC has been fixed.
  #9724

• Native unwind info generated for s390x has been fixed in the face of tail
  calls.
  #9725

v27.0.0: Release Wasmtime 27.0.0 (#9624)

27.0.0

Released 2024-11-20.

Added

• Support for the Wasm GC proposal is now complete. A new "null" GC has been
  also added which does not ever collect garbage.
  #9389
  #9392
  #9401
  #9435
  #9437
  #9438
  #9446
  #9448
  #9454
  #9455
  #9484

• Unstable WIT APIs now have feature gates configured at link-time and new
  -Scli-exit-with-code / -Snetwork-error-code options are available as well.
  #9381
  #9276

• Initial support for the wide-arithmetic proposal has been implemented.
  #9403
  #9500

• Guests on s390x now implement the "inline probestacks" for Cranelift to more
  robustly detect stack overflows.
  #9423

• Missing CLI options for the pooling allocator have been filled out.
  #9447

• Cranelift now supports 128-bit atomics on x64.
  #9459

• A new Cargo feature has been added to the wasmtime crate to reexport the
  wasmparser dependency.
  #9485

• Support for a new PyTorch backend for wasi-nn has been added.
  #9234

• A new -Cnative-unwind-info flag has been added to the wasmtime CLI.
  #9494

• Initial support for illumos has been added.
  #9535

• A new Caller::get_module_export API has been added.
  #9525

• Basic debug logging has been added to the debug info transformatino.
  #9526

Changed

• The WASI WITs vendored are now updated to 0.2.2.
  #9395

• The wasmtime-wasi-runtime-config is now named wasmtime-wasi-config.
  #9404

• Documentation on the implementation status of WebAssembly proposals has been
  updated.
  #9434

• Wasmtime's WASI documentation has been overhauled.
  #9471

• The wasi_config_preopen_dir in Wasmtime's C API now takes file/directory
  permissions.
  #9477

• Detection of libunwind vs libgcc is now done with weak symbols.
  #9479

• Winch has improved detection of unsupported features in a Config.
  #9490

• Winch now supports fuel-based interruption.
  #9472

• Wasmtime's minimum supported Rust version is now 1.80.
  #9496

• ISLE no longer supports scheme-style booleans.
  #9522

• ISLE now supports block comments.
  #9529

• Support for shared memory in the C API has been added.
  #9507

• Configuration options for guard size regions have been merged into a single
  option.
  #9528

Fixed

• Double-registration of debug information for modules in components has been
  fixed.
  #9470

• A panic on AArch64 for vector constants has been fixed.
  #9482

• A miscompile with sdiv and INT_MIN / -1 has been fixed on aarch64.
  #9541

v26.0.1: Release Wasmtime 26.0.1 (#9561)

26.0.1

Released 2024-11-05.

Fixed

• Update to cap-std 3.4.1, for #9559, which fixes a wasi-filesystem sandbox
  escape on Windows.
  CVE-2024-51745.

v25.0.3: Release Wasmtime 25.0.3 (#9562)

25.0.3

Released 2024-11-05.

Fixed

• Update to cap-std 3.4.1, for #9559, which fixes a wasi-filesystem sandbox
  escape on Windows.
  CVE-2024-51745.

v24.0.2: Release Wasmtime 24.0.2 (#9563)

24.0.2

Released 2024-11-05.

Fixed

• Update to cap-std 3.4.1, for #9559, which fixes a wasi-filesystem sandbox
  escape on Windows.
  CVE-2024-51745.

v26.0.0: Release Wasmtime 26.0.0 (#9489)

26.0.0

Released 2024-10-22.

Added

• The "table64" extension of the memory64 proposals to WebAssembly has been
  implemented.
  #9206

• Initial support has been added for compiling WebAssembly modules with Pulley,
  Wasmtime's interpreter. Note that the interpreter is not feature complete yet.
  #9240

• Wasmtime can now execute code without relying on host-based signal handlers.
  #9230

• Work has continued on implementing the GC proposals in Wasmtime.
  #9246
  #9244
  #9271
  #9275
  #9278
  #9282
  #9285
  #9326
  #9341
  #9358

• Support for ARM64 Windows has been finished with support for unwinding.
  Release binaries are now also available for this platform.
  #9266
  #9283

• The bindgen! macro now supports multiple paths to load WIT from.
  #9288

• A new -W async-stack-size=N argument has been added to the CLI.
  #9302

• A new wasmtime completion subcommand can be used to generate a completion
  script for the Wasmtime CLI.
  #9312

• Components now support initialize_copy_on_write_image like core modules.
  #9357

• Initial support for the ISLE verifier Crocus has landed.
  #9178

Changed

• Wasmtime now requires Rust 1.79.0 to compile.
  #9202

• The future-trailers.get in wasi-http now returns none when trailers are
  absent.
  #9208

• The Cranelift instructions iadd_cin and isub_bin were removed. The
  isub_borrow and iadd_carry instructions were renamed to {u,s}add_carry
  and {u,s}sub_borrow.
  #9199

• Winch now supports multi-value results on AArch64.
  #9218

• Some issues related to shutdown have been fixed with WASI sockets.
  #9225

• Cranelift now has a Cargo feature to enable support for all native ISAs and
  not Pulley.
  #9237

• Cranelift support for StructArgument in the arm64, riscv64, and s390x
  backends has been removed.
  #9258

• The pooling allocator no longer limits instances/memories/tables by default.
  #9257

• Stack overflow on an async stack will now print a message that this happened.
  #9304

• Cranelift's cranelift-wasm crate has been removed and folded directly into
  wasmtime-cranelift.
  #9313

• Cranelift's TrapCode type is now represented with a single byte.
  #9338

Fixed

• Stack slots in Cranelift are now aligned from the start instead of the end.
  #9279

• The WASIp1 adapter now correctly handles allocations where the initial
  alignment consumes the entire allocation.
  #9356