Direct selector miscompiles value-returning br_table — carried value dropped (affects --relocatable/shipped path)

[avrabe]

Summary

The direct instruction selector (select_with_stack) silently miscompiles a value-returning br_table: when a br (from a br_table arm) targets a block with a result type and carries a value, the carried value is dropped — the dispatched arms return 0 instead of their value. Only the default/fall-through arm is correct.

This is distinct from #507 (which is the optimized path dropping the dispatch for void br_table; fixed by declining to direct). This bug is in the direct selector itself, so it affects both --relocatable and --no-optimize — i.e. the shipped path (gust/falcon use --relocatable). Surfaced while gating the #507 fix: declining the optimized path to the direct selector exposed that the direct selector is also wrong for this shape.

Silent wrong-code, exit 0 — an #180/#185 Ok-or-Err violation on the shipped path.

Minimal repro

btval.wat:

(module
 (func (export "pick") (param i32) (result i32)
  (block $end (result i32)
   (block $c2
    (block $c1
     (block $c0
      (br_table $c0 $c1 $c2 (local.get 0)))
     (br $end (i32.const 10)))
    (br $end (i32.const 20)))
   (i32.const 30))))

Oracle (wasmtime): pick(0..2) → 10, 20, 30; pick(≥2) → 30.

synth (BOTH --relocatable and default→direct), executed under unicorn:

pick(0) = 0   (expect 10)   <-- carried value dropped
pick(1) = 0   (expect 20)   <-- carried value dropped
pick(2) = 30  (expect 30)   OK (default arm)

The br_table dispatch itself is correct (cases 0/1 don't fall to default), but br $end (value) doesn't deliver the value — r0 is 0 at return for the dispatched arms.

Scope / impact

• Affects the shipped --relocatable path — if gust/falcon lower a value-returning br_table (a switch-expression), it would be wrong with no diagnostic. (The one gust br_table is void-dispatch, so not hit today — needs confirming per component.)
• Blocks fully closing Optimized path silently miscompiles br_table — selector elided, all arms fall through (#483/#500 family) #507: declining the optimized path to direct (the Optimized path silently miscompiles br_table — selector elided, all arms fall through (#483/#500 family) #507 fix) makes void br_table correct, but value-returning still needs this direct-selector fix.

Likely cause

The operand-stack tracking across a br that carries a block result — the value pushed before br $end isn't materialized into the result register on the branch edge. Same family as the #313 if/else result-reconciliation machinery, but for br-to-labeled-block-with-result.

Repro files on request.

[avrabe]

Investigated this pass — full scope mapped, and the #507 decline-to-direct shortcut does NOT work here. Recording the negative result so it isn't re-attempted.

1. Confirmed on the shipped --relocatable path: pick(0)=0 / pick(1)=0 vs wasmtime 10/20 (only the default/fall-through arm is correct). Root cause: the Br handler in select_with_stack emits only a B to the target label and never materializes the carried top-of-stack value into the block's result register.

2. Scope is broader than the original repro — the carried-value drop spans Br, BrIf, and BrTable-direct to a result-typed block, each with its own repro:

   • br $end (value) (the original br_table-arm case)
   • (block (result i32) … (br_if $b) …) → taken edge returns 0
   • (block (result i32) (br_table …)) → dispatched arm returns 0

3. The decline-to-direct shortcut (what fixed Optimized path silently miscompiles br_table — selector elided, all arms fall through (#483/#500 family) #507) is unavailable. The IR carries no block-result arity (WasmOp::Block is a unit variant; the decoder tracks none), so a detect-and-decline at the branch site cannot distinguish a carried result from an unwound void-target value. Empirically: a Br/BrIf-to-non-loop-block with a non-empty vstack over-declines valid code — i32.const 1; br 2 to a void block (the value is unwound, not carried) is legal WASM that compiles correctly today, and a non-empty-stack decline wrongly refuses it (breaks 4 existing selector tests: test_complex_nested_blocks_br_to_outer, _deeply_nested_blocks, _epilogue_br_out_of_function, _complex_br_table_switch_dispatch — 3 of which are plain Br, so even a Br-only decline is unsound). No non-empty-stack heuristic is false-positive-free without arity.

4. Therefore Direct selector miscompiles value-returning br_table — carried value dropped (affects --relocatable/shipped path) #509 requires the real fix: thread block-result arity (decoder → WasmOp::Block/Loop/If → selector) + a result-register convention so every br* to a result block materializes the value before branching (the if/else-with-result lowering has no result-register reconciliation — arms agree only by register-pressure luck #313 if/else reconciliation, generalized to labeled-block branches). That's a cross-cutting, byte-changing, silicon-gated change — not a loop-tick increment.

Priority: background, not urgent — gust's br_table is void-dispatch, so no shipped artifact hits this today (confirmed in #507). Keeping open for the arity-threading fix; no decline shortcut.