Integer expression-region benchmark

tools/int-expr-region-bench.js — the integer twin of the x87 region bench (tools/x87-realistic-region-bench.js / docs/x87-realistic-region-bench.md, landing on a separate branch), answering the "x86 integer expression lowering" section of docs/semantic-expression-fusion-benchmark.md. Both of those documents are referenced by name rather than linked because they are not on this branch yet.

Question. For an x86 integer basic block with an expression-shaped interior, how much does lowering it at decode time to one dataflow expression tree — one dispatch per block, intermediates in wasm locals, only live-out registers materialized at exit, flags computed only where consumed — save over today's per-op handlers, and over the pair-fused superinstructions we already have?

Answer, in one line. On a hot block the tree is worth 10x-70x over per-op handlers, pair fusion is worth 1.0x-1.6x, and the two are not close; roughly a third to a half of the tree's win is dispatch elimination and the rest is keeping intermediates in locals, though that split is engine-dependent.

node tools/int-expr-region-bench.js
node tools/int-expr-region-bench.js --no-jsc --no-calibrate
INT_EXPR_ROUNDS=9 INT_EXPR_JSON=/tmp/out.json node tools/int-expr-region-bench.js

Method

Standalone generated WAT modules, one per arm, compiled through lib/compile-wat.js. Every arm executes the same guest program over the same architectural state and returns an i64 checksum of all of it — eight registers, the five lazy-flag words plus saved_cf, a branch accumulator, the block budget, and a 64-word window of guest memory. The driver asserts every arm agrees at every (shape, trips) point and throws instead of reporting timings when they do not. An arm that "wins" by not doing the work fails loudly. It caught a real bug during development (see Stale flag fields).

Arms are interleaved inside one process with the order rotated every round, and the median of five warm rounds is taken, because this box sits at load 10-40 and the only defensible output is a ratio between arms measured in one process. Both runs quoted here were taken at loadavg 2-4.

The five arms

The op semantics are written once, in emitOp. The arms differ only in the storage/dispatch context (C) handed to it, so an arm cannot quietly execute a different program.

Pressure and safepoints

Eight live integer registers (including esp), the lazy flag word, a branch accumulator, and a block budget decremented once per block entry with a periodic reset. Every arm pays the budget identically, so a block that costs nothing still costs that.

trips is trips per entry: entry and exit materialization are charged once per call and the block body runs trips times inside, which is what makes the trips=1 column meaningful — it is the cost of a region that runs once.

Shapes

Every shape carries a register dependency from one trip to the next, and the tool asserts it (assertLoopCarried). This is not cosmetic: an early version of dot and vec4 recomputed identical values every trip, which makes the body loop-invariant and lets an engine hoist it out of the trip loop in the straight-line arms while the dispatched arms still execute it. That would have reported dead-code elimination as a fusion win. Adding the pointer steps moved the dot tree ratio at 64 trips by less than a rounding step, so no hoisting was in fact happening — but the guard is what makes that statement checkable rather than hopeful.

Stale flag fields — the bug the checksum caught

$set_flags_logic writes only flag_op and flag_res; $set_flags_shift writes flag_op, flag_res and flag_b. So after add eax,ebx; …; sar eax,16 the architectural flag_a still belongs to the add, several ops back. A region that materializes "the last flag producer" gets this wrong. The tool therefore computes the last writer of each field (FLAG_FIELDS), not the last flag-producing op, and only that op writes that field's local. chain32 keeps this covered permanently: it ends on a logic op, so its final flag_a comes from the op before it.

Results

Ratio to arm 1 (handlers). Lower is faster. handlers ns/op is the baseline in absolute terms and is not a result — it is there so the ratios can be sanity-checked against the calibration below.

Node / V8 (v8 in-process, 5 warm rounds, loadavg 3.3)

Break-even, tree vs directmem: 1 trip on every shape. Locals are ahead from the first execution on V8; there is no crossover to wait for.

JSC (jsvu shell — labelled JSC, not Safari)

Break-even, tree vs directmem: 1 trip on dot, addr_loop, fixmul64, vec4; 4 on flag_chain and adc_chain; 64 on chain16; never within 256 trips on chain32. On JSC, wasm globals in a pure-register loop cost the same as locals.

Generated size and compile cost

Whole-module figures for all eight shapes, so treat them as a shape comparison, not as a projection budget — a real decode-time lowering emits its region at runtime.

The tree arm is 23% more wasm than the handler arm for the same eight shapes — the handler arm shares one body per opcode across every shape, the tree arm emits a specialized copy per block. That is the standing trade: code size scales with the number of blocks lowered, not with the size of the opcode set. tree_lowered is smaller than tree (SIMD collapses 16 lane ops into four instructions) but takes 4x longer to compile.

Checksum equality

checksums_equal: true on both engines, at all 32 (shape, trips) points, for all five arms — including the SIMD and i64 rewrites in tree_lowered, which is the only evidence offered that those rewrites are exact rather than approximately right.

Calibration against the real emulator

The same fixed-point dot body, hand-encoded as x86 and injected into a live build/wine-assembly.wasm instance the way tools/bench-loops.js does, so it runs through the production decoder, $next and the real handlers:

real emulator, dot shape          14.76 ns per dispatched guest op
synthetic `handlers` arm, dot      8.66 ns per dispatched guest op
synthetic baseline is 59% of real handler cost

The synthetic baseline is roughly 1.7x optimistic, so every ratio above is conservative. The missing 41% is the machinery the synthetic arm does not model: the block-cache lookup, $run's block loop and budget, and the full $g2w path behind each memory-form handler. A real region replaces that too, so the true saving on a hot block is larger than the table says, not smaller.

Two caveats that push the other way, and neither is small:

• The dispatch arms are flattered. Like bench-loops.js, a short periodic program lets the branch predictor learn every call_indirect target, and the mispredict is a real share of $next in a live profile (interpreter-dispatch-perf.md). This understates dispatch cost by construction.
• Nothing here says the shapes occur. tools/find-loops.js, tools/match-loops.js and --handler-hist answer that, and the honest prior from loop-idiom-superops-design.md is that only ~2% of static self-loops match today's matcher, with call and multi-branch accounting for 58% of declines. Never quote a ratio from this table as an application speedup — multiply it by the profile share of the blocks a lowering would actually cover.

Verdict

(a) Tree vs pair-fused — not close, and they are not the same lever

Pair fusion is worth 0-45% (ratio 0.58-1.00, mostly 0.65-0.93). The tree is worth 10x-70x at 64+ trips and still 1.4x-2.5x at a single trip.

The reason is structural, not a matter of degree. Pair fusion removes one dispatch in two and nothing else: the fused handler still reads its register roles out of an operand word through br_table, still writes the register file per op, still stores four flag globals per ALU op. It recovers the dispatch half of one op in two, which is exactly where the numbers land — adc_chain at one trip is 1.000, i.e. pair fusion bought literally nothing there. Wherever pair fusion looks good (vec4 0.62, addr_loop 0.65) the shape is load/imul/add/store, and what is being removed is a dispatch between two ops that were already going to touch the same register.

The tree removes the representation: no operand decode, no register file, no flag encoding, no intermediates in memory. Doing half of that badly does not get you halfway.

A pair-fusion program is not a cheap first step toward regions. It is a different, much smaller effect that does not compose with the region work, and the effort spent enumerating profitable pairs does not carry over.

(b) Locals vs direct memory — locals are most of the win on V8, and none of it on JSC in the easy case

Splitting the tree's win in two, at 64 trips:

On V8 the two factors are comparable and locals are often the bigger one — vec4 goes 1.00 -> 0.131 on dispatch and then 0.131 -> 0.018 on locals, a further 7x. Break-even is 1 trip on every shape: there is no amortization to wait for, because both arms pay the same entry/exit and the difference is pure per-op storage cost.

On JSC the split is the other way round, and for pure-register chains it vanishes: chain16 and chain32 are identical in tree and directmem to three digits (0.021 vs 0.021, 0.019 vs 0.019), with break-even at 64 and beyond 256 respectively. JSC keeps wasm globals in registers across a loop when nothing else is contending; V8 in these modules does not.

So "put the intermediates in locals" is a V8-shaped optimization. It is still the right default — it is never worse on either engine, and on the memory-touching shapes it is worth 2-3x on JSC too — but the 5-10x figure people will quote from the V8 column is not a portable number, and a design that depends on it should say so.

(c) Better lowering — pays exactly where an idiom exists, and one of the three was already free

Three rewrites, three different answers:

The constant-multiply strength reduction is a no-op, and slightly negative on JSC — the wasm engine already lowers i32.mul by a constant, so re-doing it in the IR only adds nodes for the engine to fold back. That is the reusable lesson: do not re-implement optimizations the wasm backend already performs. The two rewrites that pay are both ones the backend cannot do, because they change what the architectural state means — dropping the edx:eax split that shrd exists to undo, and proving four lanes independent when they are written through the same architectural register.

So arm 4 is worth having, but only as a small named set of idiom rewrites, not as a general "optimize the tree" pass. And it costs: tree_lowered compiles 4x slower than tree.

(d) The adc control — behaves exactly as a barrier should, which is what makes the rest believable

adc_chain is the worst tree ratio at every trip count on both engines:

at 64 trips, V8:   adc_chain 0.096   everything else 0.018 - 0.075
at 64 trips, JSC:  adc_chain 0.097   everything else 0.021 - 0.119
at 1 trip:         adc_chain 0.728 / 0.729  — the worst on both

and pair fusion on it is 1.000 at one trip on V8 — no gain at all.

This is the correct shape of a null result rather than a flat one. The tree still wins something (~10x at 64 trips) because it drops the operand decode and the register file, which every arm-3 shape gets for free. What it cannot drop is the flag dataflow: every adc consumes CF from the op before it, so the lazy-flag elimination that carries the other shapes is switched off here, the three ops stay a serial dependency chain, and there is no tree to build. The gap between 0.096 and the 0.018 of chain16 — five times less benefit for a block of the same arithmetic weight — is the value of flag laziness, measured.

That the control moves in the right direction by the right amount, rather than scoring 1.00 or scoring like everything else, is the reason to trust the rest of the table.

What this does not answer

• Whether the blocks in real guest code are expression-shaped. See tools/match-loops.js --why; call and multi-branch are 58% of declines today, and neither is in this benchmark.
• Side exits. Every shape here runs to completion. A region that must materialize all live architectural state and fall back to the scalar interpreter mid-block pays a cost this bench never charges.
• Partial-register writes (AL/AH/AX), DIV traps, and possibly-aliasing load/store pairs — the brief lists all three as near-misses and all three are barriers we have not priced.
• Chrome. tools/profile-web-frames.js drives the app page, not a bare wasm module, so there is no trivial path; V8-in-Node is reported instead and JSC is the second engine.