pulley: Implement `return_call` instructions (#9834)* pulley: Implement `return_call` instructionsThis commit fleshes out the Cranelift lowerings of tail calls which getsthe wasm tail call propo
pulley: Implement `return_call` instructions (#9834)* pulley: Implement `return_call` instructionsThis commit fleshes out the Cranelift lowerings of tail calls which getsthe wasm tail call proposal itself working on Pulley. Most of the bitsand pieces here were copied over from the riscv64 backend and thenedited to suit Pulley.* Fix table64 addressing on 32-bit
show more ...
Refactor how wasm features are calculated for `*.wast` tests (#9560)* Refactor how wasm features are calculated for `*.wast` testsThis commit refactors the `tests/wast.rs` test suite which runs a
Refactor how wasm features are calculated for `*.wast` tests (#9560)* Refactor how wasm features are calculated for `*.wast` testsThis commit refactors the `tests/wast.rs` test suite which runs all ofthe upstream spec tests as `*.wast` files as well as our own`misc_testsuite` which has its own suite of `*.wast` files. Previouslythe set of wasm features active for each test was a sort of randommishmash and convoluted set of conditionals which was updated and editedover time as upstream proposal test suites evolved. This was thenmirrored into our own conventions for `misc_testsuite` as well. Overallthough this has a number of downsides I'm trying to fix here:* The calculation of what features are enabled is quite complicated and effectively a random mishmash of `||` conditionals with hierarchies that don't make any sense beyond "this is just required to get things to pass".* There is no means of per-test configuration. For example `canonicalize-nans.wast` had hardcoded logic in `tests/wast.rs` that it needed a different setting turned on in `Config`.* There was no easy means to write tests for Wasmtime which take a union of a number of proposals together without having lots of sub-folders that may not make sense.* Tests that require a particular proposal had to have duplicate logic for Winch as it doesn't support the full suite of features of all proposals that Cranelift does.The new system implemented in this commit takes a leaf out of the`disas` tests. There is a new `TestConfig` structure in the`tests/wast.rs` harness which is decoded from each test (leading `;;!`comments) which enables specifying, in each test, what's required. Thisencompasses many wasm proposals but additionally captures other behaviorlike nan-canonicalization. This means that all test files in`misc_testsuite/**/*.wast` are now manually annotated with what wasmfeatures they require and what's needed to run. This makes per-testconfiguration much easier, per-config-setting much easier, and blanketignore-by-proposal for Winch much easier as well.For spec tests we can't modify the contents of the upstream `*.wast`files. To handle this they're handled specially where `TestConfig` ismanually created and manipulated for each spec proposal and the maintest suite itself. This enables per-proposal configuration that doesn'tleak into any others and makes it more obvious what proposals are doingwhat.* Hack around Winch support for aarch64
Wasmtime: Add support for Wasm tail calls (#6774)* Wasmtime: Add support for Wasm tail callsThis adds the `Config::wasm_tail_call` method and `--wasm-features tail-call`CLI flag to enable the Wa
Wasmtime: Add support for Wasm tail calls (#6774)* Wasmtime: Add support for Wasm tail callsThis adds the `Config::wasm_tail_call` method and `--wasm-features tail-call`CLI flag to enable the Wasm tail calls proposal in Wasmtime.This PR is mostly just plumbing and enabling tests, since all the prerequisitework (Wasmtime trampoline overhauls and Cranelift tail calls) was completed inearlier pull requests.When Wasm tail calls are enabled, Wasm code uses the `tail` callingconvention. The `tail` calling convention is known to cause a 1-7% slow down forregular code that isn't using tail calls, which is why it isn't usedunconditionally. This involved shepherding `Tunables` through to Wasm signatureconstruction methods. The eventual plan is for the `tail` calling convention tobe used unconditionally, but not until the performance regression isaddressed. This work is tracked inhttps://github.com/bytecodealliance/wasmtime/issues/6759Additionally while our x86-64, aarch64, and riscv64 backends support tail calls,the s390x backend does not support them yet. Attempts to use tail calls on s390xwill return errors. Support for s390x is tracked inhttps://github.com/bytecodealliance/wasmtime/issues/6530* Store `Tunables` inside the `Compiler`Instead of passing as an argument to every `Compiler` method.* Cranelift: Support "direct" return calls on riscv64They still use `jalr` instead of `jal` but this allows us to use the `RiscvCall`reloc, which Wasmtime handles. Before we were using `LoadExternalName` whichproduces an `Abs8` reloc, which Wasmtime intentionally does not handle sincethat involves patching code at runtime, which makes loading code slower.* Fix tests that assume tail call support on s390x