* All: Drop 'basic-blocks' feature
This makes it so that 'basic-blocks' cannot be disabled and we can
start assuming it everywhere.
* Tests: Replace non-bb filetests with bb version
* Tests: Adapt solver-fixedconflict filetests to use basic blocks
This commit aligns the representation of stackmaps to be the same
as Spidermonkey's by:
* Reversing the order of the bitmap from low addresses to high addresses
* Including incoming stack arguments
* Excluding outgoing stack arguments
Additionally, some accessor functions were added to allow Spidermonkey
to access the internals of the bitmap.
Spidermonkey will need to emit pre/post barriers for global.set/get to a
reference type. #1176 and #1299 plan to add a template concept that could
be used to implement this. Once that has been stabilized, we should be able
to remove this code in favor of templates easily.
This commit introduces environment functions to handle the translation of
reference type instructions, analogous to how bulk-memory was implemented.
Additionally, the bulk-memory instructions that operate on tables are extended
to support multiple table indices.
If/when Cranelift gains a `load_splat` instruction, the `load + splat` could be replaced with a single Cranelift `load_splat`. This change allows the `simd_load_splat.wast` spec test to pass.
* Use `is_wasm_parameter` in translating wasm calls
Added in #1329 it's now possible for multiple parameters to be non-wasm
parameters, so the previous `param_types` method is no longer suitable
for acquiring all wasm-related parameters, rather then `FuncEnvironment`
must be consulted. This removes usage of `param_types()` as a method
from the wasm translation and instead adds a custom method inline for
filtering the parameters based on `is_wasm_parameter`.
* Apply feedback
* Run rustfmt
* Don't require `mut`
* Run rustfmt
* Bitcast vectors immediately before a return
* Bitcast vectors immediately before a block end
* Use helper function for bitcasting arguments
* Add FuncTranslationState::peekn_mut; allows mutating of peeked values
* Bitcast values in place, avoiding an allocation
Also, retrieves the correct EBB header types for bitcasting on Operator::End.
* Bitcast values of a function with no explicit Wasm return instruction
* Add Signature::return_types method
This eliminates some duplicate code and avoids extra `use`s of `Vec`.
* Add Signature::param_types method; only collect normal parameters in both this and Signature::return_types
* Move normal_args to Signature::num_normal_params method
This matches the organization of the other Signature::num_*_params methods.
* Bitcast values of Operator::Call and Operator::CallIndirect
* Add DataFlowGraph::ebb_param_types
* Bitcast values of Operator::Br and Operator::BrIf
* Bitcast values of Operator::BrTable
Due to SIMD's v128 operations, vectors that may have had an explicit type (e.g. f32x4) before a v128 operation will subsequently have CLIF's v128 stand-in type: i8x16. In order for follow-on operations (that may be more stricly typed, e.g. f32x4.add) to avoid CLIF errors, we must bitcast them back to the operation type. The raw_bitcast operation used to do this emits no machine code but does incur some small compile-time cost; it would be nice to avoid this in the future.
We weren't previously keeping track of quite the right information for whether
an `if .. else .. end`'s following block was reachable or not. It should be
reachable if the head is reachable and either the consequent or alternative end
reachable (and therefore fall through to the following block) or do an early
`br_if` to it.
This commit rejiggers `ControlStackFrame::If` to keep track of reachability at
the end of the consequent (we don't need to keep track of it at the end of the
alternative, since that is simply `state.reachable`) and adds Wasm tests for
every reachability situation we can encounter with `if .. else .. end`.
Fixes#1132
* cranelift-wasm: replace `WasmTypesMap` with `ModuleTranslationState`
The `ModuleTranslationState` contains information decoded from the Wasm module
that must be referenced during each Wasm function's translation.
This is only for data that is maintained by `cranelift-wasm` itself, as opposed
to being maintained by the embedder. Data that is maintained by the embedder is
represented with `ModuleEnvironment`.
A `ModuleTranslationState` is returned by `translate_module`, and can then be
used when translating functions from that module.
* cranelift-wasm: rename `TranslationState` to `FuncTranslationState`
To disambiguate a bit with the new `ModuleTranslationState`.
* cranelift-wasm: Reorganize the internal `state` module into submodules
One module for the `ModuleTranslationState` and another for the
`FuncTranslationState`.
* cranelift-wasm: replace `FuncTranslator` with methods on `ModuleTranslationState`
`FuncTranslator` was two methods that always took ownership of `self`, so it
didn't really make sense as an object as opposed to two different functions, or
in this case methods on the object that actually persists for a longer time.
I think this improves ergonomics nicely.
Before:
```rust
let module_translation = translate_module(...)?;
for body in func_bodies {
let mut translator = FuncTranslator::new();
translator.translate(body, ...)?;
}
```
After:
```rust
let module_translation = translate_module(...)?;
for body in func_bodies {
module_translation.translate_func(body, ...)?;
}
```
Note that this commit does not remove `FuncTranslator`. It still exists, but is
just a wrapper over the `ModuleTranslationState` methods, and it is marked
deprecated, so that downstream users get a heads up. This should make the
transition easier.
* Revert "cranelift-wasm: replace `FuncTranslator` with methods on `ModuleTranslationState`"
This reverts commit 075f9ae933bcaae39348b61287c8f78a4009340d.
This commit fixes a bug where at the end of an `if..else..end`'s consequent
block, we would sometimes erroneously jump to the `else` block instead of to the
following destination block. Not good!
This commit introduces initial support for multi-value Wasm. Wasm blocks and
calls can now take and return an arbitrary number of values.
The encoding for multi-value blocks means that we need to keep the contents of
the "Types" section around when translating function bodies. To do this, we
introduce a `WasmTypesMap` type that maps the type indices to their parameters
and returns, construct it when parsing the "Types" section, and shepherd it
through a bunch of functions and methods when translating function bodies.
Only i16x8 and i32x4 are encoded in this commit mainly because i8x16 and i64x2 do not have simple encodings in x86. i64x2 is not required by the SIMD spec and there is discussion (https://github.com/WebAssembly/simd/pull/98#issuecomment-530092217) about removing i8x16.
