Fixing Cranelift x86_64: select_spectre_guard with an i128 condition is not implemented

This failure happens because the x86_64 backend can lower select_spectre_guard only when the condition can be translated into a supported flag-producing compare sequence. An i128 condition falls outside that path, so legalization or instruction selection reaches an unimplemented backend case and aborts instead of rewriting the IR into something the target knows how to emit.

Understanding the Root Cause

The key detail is that select_spectre_guard is not just a regular value select. It is a Spectre-mitigation-aware selection primitive that depends on target-specific lowering rules. On x86_64, many guarded-select style operations eventually rely on a condition represented through machine flags or through condition codes derived from supported integer comparisons.

That breaks down for i128 because native 128-bit scalar integer condition handling is not directly available as a single compare in the x86_64 backend. Cranelift usually models i128 with multi-register values, and backend support must explicitly define how to:

• compare the low and high halves,
• combine the partial results into a final boolean condition, and
• feed that condition into select_spectre_guard lowering safely.

If that legalization path does not exist, the compiler reaches a target-specific not implemented branch. This is why the bug looks similar to earlier issues involving select: both operations need a legal target-level condition, but select_spectre_guard adds an extra backend-sensitive lowering requirement.

In practice, the unsupported case is usually triggered by one of these patterns:

• a direct select_spectre_guard whose condition value is typed as i128,
• a compare or transformation producing an i128-typed value that is used as a guard,
• missing legalization that should have converted the condition into an i8, b1, or flag-compatible form before instruction selection.

Step-by-Step Solution

The safest fix is to ensure the backend never sees select_spectre_guard with an i128 condition directly. Instead, legalize the IR earlier so the condition becomes a supported boolean or a narrower integer derived from explicit i128 comparison lowering.

1. Reproduce the failure with a focused test

Create a minimal .clif test that isolates the unsupported path. The exact shape can vary, but the important part is that the guard condition is effectively i128-based.

test interpret --target x86_64 has_spectre_mitigation_enabled=true

function %bad(i128, i64, i64) -> i64 {
block0(v0: i128, v1: i64, v2: i64):
    v3 = iconst.i128 0
    v4 = icmp ne v0, v3
    v5 = select_spectre_guard v4, v1, v2
    return v5
}

If your failing fuzz case passes an actual i128 value where a boolean-like guard is expected, reduce it until the backend crash or panic is still visible. That makes the legalization gap obvious and gives you a regression test.

2. Identify where legalization should happen

There are two common places to fix this:

• IR legalization: rewrite unsupported i128-based guard conditions before backend lowering.
• x86_64 lowering: add explicit support for lowering i128 comparisons into machine operations and then map the result into the guarded select sequence.

For this issue, legalization is typically the cleaner option because it avoids teaching every backend-specific guarded-select path about multiword integer conditions.

3. Rewrite the guard into a supported condition form

If the condition conceptually means “non-zero i128”, lower it into explicit half comparisons and combine them before calling select_spectre_guard. For example:

; Pseudocode legalization idea
lo = ireduce.i64 v0
hi = ushr_imm v0, 64
hi64 = ireduce.i64 hi
lo_nz = icmp ne lo, 0
hi_nz = icmp ne hi64, 0
cond = bor lo_nz, hi_nz
result = select_spectre_guard cond, v1, v2

If the original condition came from an i128 comparison like equality or ordering, lower that comparison first into supported high/low half logic. For equality:

; a == b for i128
alo = ireduce.i64 a
ahi = ireduce.i64 (ushr_imm a, 64)
blo = ireduce.i64 b
bhi = ireduce.i64 (ushr_imm b, 64)
lo_eq = icmp eq alo, blo
hi_eq = icmp eq ahi, bhi
both_eq = band lo_eq, hi_eq
result = select_spectre_guard both_eq, x, y

For ordering comparisons, compare the high halves first, then the low halves if needed, taking signedness into account.

4. Implement the legalization in Cranelift

The exact file depends on the current Cranelift layout, but the change usually belongs in the part of the compiler responsible for legalizing unsupported integer widths or expanding high-level instructions before ISel.

The implementation strategy is:

1. Detect select_spectre_guard whose condition originates from or is represented by an unsupported i128 form.
2. Expand the condition into legal sub-operations on i64 halves.
3. Rebuild select_spectre_guard using the legalized boolean result.
4. Ensure the x86_64 backend only receives a condition type it already supports.

Representative pseudocode:

match inst_data(op) {
    Opcode::SelectSpectreGuard => {
        let cond = inputs[0];
        let t = dfg.value_type(cond);

        if t == types::I128 {
            let zero = pos.ins().iconst(types::I128, 0);
            let legalized_cond = expand_i128_nonzero_compare(pos, cond, zero);
            let x = inputs[1];
            let y = inputs[2];
            let new_val = pos.ins().select_spectre_guard(legalized_cond, x, y);
            replace(inst, new_val);
        }
    }
}

If the condition is already the result of an icmp on i128, then the better place is often the compare legalization helper:

fn expand_i128_icmp(cc, lhs, rhs) -> Value {
    let lhs_lo = ...;
    let lhs_hi = ...;
    let rhs_lo = ...;
    let rhs_hi = ...;

    match cc {
        IntCC::Equal => {
            let hi_eq = ...;
            let lo_eq = ...;
            band(hi_eq, lo_eq)
        }
        IntCC::NotEqual => {
            let hi_ne = ...;
            let lo_ne = ...;
            bor(hi_ne, lo_ne)
        }
        _ => {
            // Ordered compare expansion using hi-first logic.
        }
    }
}

Once icmp.i128 is legalized into a backend-supported boolean, select_spectre_guard can remain unchanged and simply consume the legalized result.

5. Add a regression test

Add a backend test that specifically covers x86_64 + Spectre guard + i128-derived condition. This prevents future regressions when legalization or instruction selection changes.

test compile --target x86_64 has_spectre_mitigation_enabled=true

function %guard_i128_eq(i128, i128, i64, i64) -> i64 {
block0(a: i128, b: i128, x: i64, y: i64):
    c = icmp eq a, b
    r = select_spectre_guard c, x, y
    return r
}

You should also include a non-zero test case if that pattern is legal in the IR that fuzzing generated.

6. Verify with target-specific and interpreter tests

Run the relevant Cranelift test suites after applying the legalization:

cargo test -p cranelift-codegen
cargo test -p cranelift-filetests
cargo test select_spectre_guard
cargo test i128

If your local workflow uses filetests heavily, also run the x86_64 backend tests directly and confirm the generated code no longer reaches the unimplemented path.

Common Edge Cases

• Signed vs unsigned ordering: Equality expansion is straightforward, but sgt, slt, ugt, and ult on i128 require different high-half comparison rules. A wrong signedness check will silently generate incorrect code.
• Boolean representation mismatches: Some parts of the pipeline expect a canonical boolean value, while others rely on machine flags. Legalization must produce the form expected by the next phase.
• Backend-only fixes that miss other targets: If you patch only x86_64 instruction selection, another backend may fail on the same IR later. General legalization is usually more robust.
• Spectre mitigation semantics: select_spectre_guard is security-sensitive. Rewriting it as a plain select is not equivalent and may remove the intended mitigation behavior.
• Multi-result compare lowering bugs: For ordered i128 comparisons, low-half checks should only matter when high halves are equal. Getting this wrong causes rare but serious correctness issues.
• Constant folding interactions: If one side of the i128 compare is constant zero, some optimization passes may simplify the expression before or after legalization. Make sure the transformed IR still reaches a supported backend path.

FAQ

Why does this fail on x86_64 if the condition is logically just true or false?

Because the backend does not operate on abstract truth values alone. It needs a legal machine-level representation of that condition. An i128 value or compare often requires expansion into multiple native operations first.

Can I fix this by converting select_spectre_guard into a normal select?

No. select_spectre_guard exists for Spectre-related mitigation semantics. Replacing it with select may compile, but it can change the security properties of the generated code.

Should the fix live in legalization or in the x86_64 backend?

Usually legalization is the better fix for this specific issue. It keeps unsupported i128 conditions away from backend-specific lowering paths and makes behavior more consistent across targets.

The durable fix is simple in principle: never let select_spectre_guard on x86_64 consume an unsupported i128-typed condition directly. Expand the i128 comparison or non-zero test into legal i64-based pieces, rebuild a proper boolean guard, and cover it with regression tests so the backend never hits the unimplemented case again.