perf: fold LSB-test i32.and X 1 into i32.ctz in boolean contexts

[ggreif]

Summary

An if-else conditioned on (i32.and X (i32.const 1)) tests the least significant bit of X. Since i32.ctz X == 0 iff the LSB of X is set, we can replace the condition with i32.ctz X and swap the branches — saving one instruction.

The second commit extends this to the primary pattern from the issue — eqz(and X 1) as a boolean condition (used in br_if, if, select) — handled in optimizeBoolean so all three sites benefit from one insertion.

• Handles the constant on either side (left or right of and)
• visitIf: (and X 1); if T E → (ctz X); if E T
• optimizeBoolean: eqz(and X 1) → ctz X — covers the typical br_if (eqz (and X 1)) pattern

Motivation

Filed in #5752. The Motoko compiler already implements this in its own peephole optimizer (instrList.ml); the goal is to bring it to wasm-opt so that hand-written Wasm (e.g. the Motoko RTS, written in Rust) benefits too.

The optimizeBoolean rule alone fires 26–105 times across the three Motoko RTS variants (mo-rts-eop, mo-rts-incremental, mo-rts-non-incremental), targeting the is_skewed/is_scalar pointer-tagging checks in the GC hot path.

Applying wasm-opt --optimize-instructions to the Motoko RTS and running the benchmark suite shows the following gross effects (the submitted optimisation is a contributing factor alongside other rules triggered in the same pass):

Benchmark	Before	After	Δ
heap-32 (GC-heavy, run 1)	1,153,792,735 instr	1,151,398,207 instr	−2,394,528 (−0.21%)
heap-32 (run 2)	1,256,407,315 instr	1,253,408,059 instr	−2,999,256 (−0.24%)
heap-64 (run 1)	1,324,057,357 instr	1,321,855,449 instr	−2,201,908 (−0.17%)
heap-64 (run 2)	1,295,845,087 instr	1,293,744,743 instr	−2,100,344 (−0.16%)
bignum	2,504,499 cycles	2,504,383 cycles	−116
candid-subtype-cost	1,115,011 cycles	1,114,823 cycles	−188

The GC-heavy heap benchmarks benefit most, consistent with the is_skewed check firing frequently during pointer traversal.

Test plan

• New lit test test/lit/passes/optimize-instructions-lsb-if.wast covers if (const left and right) and br_if (eqz (and X 1))
• All three test cases produce i32.ctz in the output

🤖 Generated with Claude Code

[kripken]

Interesting. I worry this is not always faster, though: AND usually has a cost of 1, while TZCNT often has 2: https://www.agner.org/optimize/instruction_tables.pdf

Perhaps check what LLVM does here? They likely reasoned about this thoroughly.

[ggreif]

Interesting. I worry this is not always faster, though: AND usually has a cost of 1, while TZCNT often has 2: https://www.agner.org/optimize/instruction_tables.pdf

Perhaps check what LLVM does here? They likely reasoned about this thoroughly.

I have answered a similar question here.

The i32.ctz approach is also semantically cleaner: it captures the "is LSB set?" intent more directly than and 1; eqz.

[kripken]

I agree it might be cleaner in a way. I also agree that VMs could alter what they emit, as you wrote in the linked issue. However, if this would regress performance on major VMs right now, we'd want to wait for them to fix that before landing anything.

[MaxGraey]

Even if JIT compilers start optimizing similarly to wasmtime, it still won’t solve the performance issue, for example, in runtimes with interpreters (some smart contracts, embedded oriented like wasm3 and etc). If such optimization is to be done at all, in my opinion, it should only be for “optimized for size” (-Os).

[ggreif]

Even if JIT compilers start optimizing similarly to wasmtime, it still won’t solve the performance issue, for example, in runtimes with interpreters (some smart contracts, embedded oriented like wasm3 and etc). If such optimization is to be done at all, in my opinion, it should only be for “optimized for size” (-Os).

That went through my thoughts too. I'll submit a revision soon.