wasmerio/wasmer · error

Currently only SIMD instructions are mapped to their return

Error message

Currently only SIMD instructions are mapped to their return type; the following instruction is not mapped: {:?}

What it means

Cranelift's internal type_of helper maps Wasm SIMD operators to their result WasmType for type inference during translation; it is only written to cover SIMD instructions. If a non-SIMD operator reaches it, it panics. This is an internal translation-table completeness guard, normally unreachable from user code.

Source

Thrown at lib/compiler-cranelift/src/translator/code_translator.rs:3687

        | Operator::F64x2Sqrt
        | Operator::F64x2Add
        | Operator::F64x2Sub
        | Operator::F64x2Mul
        | Operator::F64x2Div
        | Operator::F64x2Min
        | Operator::F64x2Max
        | Operator::F64x2PMin
        | Operator::F64x2PMax
        | Operator::F64x2RelaxedMin
        | Operator::F64x2RelaxedMax
        | Operator::F64x2RelaxedMadd
        | Operator::F64x2RelaxedNmadd
        | Operator::F64x2Ceil
        | Operator::F64x2Floor
        | Operator::F64x2Trunc
        | Operator::F64x2Nearest => F64X2,

        _ => unimplemented!(
            "Currently only SIMD instructions are mapped to their return type; the \
             following instruction is not mapped: {:?}",
            operator
        ),
    }
}

/// Some SIMD operations only operate on I8X16 in CLIF; this will convert them to that type by
/// adding a raw_bitcast if necessary.
fn optionally_bitcast_vector(
    value: Value,
    needed_type: Type,
    builder: &mut FunctionBuilder,
) -> Value {
    if builder.func.dfg.value_type(value) != needed_type {
        builder.ins().bitcast(
            needed_type,
            MemFlagsData::new().with_endianness(ir::Endianness::Little),

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Update Wasmer to a version that maps the offending instruction
2. Check whether the instruction requires an engine feature flag and enable it explicitly so the correct translation path runs
3. File a bug with the exact instruction name from the panic message
4. Downgrade/normalize the Wasm module (e.g. re-emit without the new opcodes via wasm-tools)

Example fix

// before
_ => unimplemented!(
    "Currently only SIMD instructions are mapped to their return type; the \
     following instruction is not mapped: {:?}",
    operator
),
// after
Operator::F32x4RelaxedSwizzle => F32X4, // add the missing opcode arm
_ => unreachable!("type_of called with non-SIMD operator: {:?}", operator),

// Before compiling, ensure the module's opcodes are supported by the installed Wasmer
// e.g. reject unknown relaxed-SIMD proposals:
let features = Features { simd: true, relaxed_simd: false, ..Default::default() };
// compiling with relaxed_simd disabled makes unknown relaxed opcodes a validation error, not a panic

When it happens

Trigger: translate_operator calls type_of with an operator not present in the SIMD mapping (e.g. a scalar or newly added relaxed-simd instruction) — typically after a new Wasm proposal's opcodes are parsed but not yet added to the mapping.

Common situations: Using a cutting-edge Wasmer build with newly standardized relaxed SIMD/GC instructions whose type mapping lags; compiling modules that use very new opcodes with an older Wasmer version.

Related errors

• unimplemented operator {operator:?}
• global #{} is a constant
• Unhandled inner case
• cannot create debug directory: {}
• x86 support requires SSE2

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/6ed0bf8606274073. Report an issue: GitHub.