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.

[ggreif]

Pushed a revision: the LSB→ctz fold is now gated on getPassOptions().shrinkLevel >= 1, so it fires under -Os / -Oz only and stays out of the default and speed-optimised pipelines. The lit test was split into DEFAULT (fold suppressed) and SHRINK (fold fires) prefixes.

[tlively]

It seems we could do something similar when there is no i32.eqz in the input as well:

(i32.and X (i32.const 1))
=>
(i32.eqz (i32.ctz X))

This would save one byte and would often be further optimized by removing the i32.eqz and flipping the branches in the next iteration.

In fact, I think we could optimize only the pattern without i32.eqz in the input and depend on the existing optimizations to remove the outer i32.eqz to cover all the cases this PR already covers.

[tlively]

Let's add tests for select as well.

[kripken]

How about making this >= 2, i.e., only in -Oz? -Os is meant to be a good balance between size and speed, and without more data I'm not sure how balanced this is. -Oz is "size at all costs".

[ggreif]

I don't think so, as (i32.and X (i32.const 1)) would often feed conditionals and the proposed transform would unlock ripple effects. This is not only space but also time saving.

[ggreif]

Added select coverage in the same lit test — two cases (constant on the right, constant on the left of the AND), non-constant arms so an unrelated select c1 c0 P → P simplification doesn't eat the select before the boolean fold runs. DEFAULT keeps the AND form (with the eqz-arm-swap that was already there); SHRINK collapses to ctz.

[MaxGraey]

(i32.and X (i32.const 1))

Even if such an expression is one byte larger compare to (i32.eqz (i32.ctz X)), it's fairly stable and repetitive since it's a predicate. That means compression will handle it very well due to sufficient dictionary-friendly entropy. Is it even worth it, considering that for interpreters and 1-tier compilers we consistently end up with a heavier instruction?