Avoid bit-loop lowering of 256-bit division and remainder by elle-j · Pull Request #576 · paritytech/revive

elle-j · 2026-07-14T13:19:27Z

Description

Any 256-bit div/sdiv/mod/smod/mulmod/addmod whose operands are not provably narrow compiles to a bit-at-a-time shift/subtract loop (one quotient bit per iteration) with no hardware divide. LLVM's ExpandLargeDivRem expands any integer div/rem wider than 128 bits into that loop before instruction selection.

An existing pass already spares the operands it can prove fit a smaller type, so the gap is everything else (e.g. runtime values, mulmod internals). __mulmod alone is 8,480 bytes / 2,923 instructions with zero divu.

The issue was detected with a contract using mulmod in resolc-compiler-tests PR17 (which further explains runtime implications).

Note

This PR explores the feasibility/benefits/effects of algorithms that avoid the expensive bit-loop lowering. The word-width-microbench workload added in the resolc-compiler-tests PR ☝️ chains mulmod with the constant P-256 field prime, which additionally motivates the constant-modulus specialization explored here.

Changes

The target already has an efficient wide-divide primitive: an i128 divide lowers to the linked compiler-rt libcall __udivti3, which uses hardware 64-bit divu. The fix in this PR expresses 256-bit division with 128-bit "digits" so its core divide stays at i128 and never triggers the bit loop. On top of that, divisions and modular multiplications by compile-time constants skip runtime division entirely via Barrett reduction (multiply by a precomputed reciprocal plus a bounded number of conditional corrections).

stdlib.ll:
- Adds __udivrem256 (Knuth Algorithm D, 128-bit digits)
- Adds __udiv256/__urem256 wrappers
- Adds __sdiv256/__srem256 signed wrappers (sign-magnitude over the unsigned routine)
- Adds __urem512by256 for mulmod's 512-by-256 reduction
- Adds __mulmod_barrett (constant-modulus Barrett reduction, HAC 14.42 at t = 256; needs no operand pre-reduction since its bound holds for any 512-bit product)
  - Barrett reduction added in commit 6b87577
- Rewrites __mulmod to use them
- Removed the now-dead __ulongrem/__clz
  - __clz removed in favor of llvm.ctlz
- Implemented and scrutinized by Claude Fable 5
llvm-context:
- Extends the existing late narrowing pass into lower_wide_division: any i256 udiv/urem/sdiv/srem it cannot prove narrowable is rewritten into a call to the matching __udiv256/__urem256/__sdiv256/__srem256.
  - i256 udiv/urem by a non-power-of-two constant is instead rewritten into a generated per-constant Barrett helper (constant_division.rs), measurably faster per call than the routed routine.
  - It runs after LLVM's optimization passes and before backend codegen (i.e. before ExpandLargeDivRem) so it covers div/mod/sdiv/smod reductions.
  - Both the Yul and newyork pipelines share this, so this addresses both.
- Adds specialize_constant_modulus_mulmod
  - Before the main pipeline inlines __mulmod away, a small constant-folding pre-pass exposes composed moduli and eligible calls are rewritten (256-bit constants to __mulmod_barrett, powers of two to inline mul+mask); lower_wide_division repeats the sweep post-pipeline. Skipped at -O0 and for modules without __mulmod calls.

Results

`mulmod` example

The table below is based only on the following contract example (Yul pipeline with -Oz, the default):

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;
contract Mulmod {
    function mm(uint256 a, uint256 b, uint256 m) external pure returns (uint256) {
        return mulmod(a, b, m);
    }
}

Metric	Before	After
PVM blob	11,917 B	8,188 B (−31.3%)
`.L__mulmod` symbol	8,480 B	982 B (−88.4%)
blob instructions	3,199	2,256 (−29.5%)
i256 bit-loop divisions	5	0 (−100%)
hardware divide	none	via `__udivti3`

Instruction counts are the Instructions totals reported in the pvmasm dump (final code after --gc-sections).

Dynamic cost

The table shows dynamic cost, measured (by Claude Fable 5 via revive-runner) as pallet-revive ref_time (of an entire contract call) per call on the same runner (full-width operands, runtime divisors unless marked constant).

Fixed per-call overhead is included, it is not the ref_time of the division instruction sequence alone. Thus the table's ratios will understate the speedup of the division itself. (Barrett reduction added in commit 6b87577.)

Op	Before	After (routing only)	After (routing + Barrett)
mulmod (m >= 2^128)	1,824,813,639	292,305,859 (6.24x)	same as routing only
mulmod (m < 2^128)	1,960,393,448	134,140,552 (14.61x)	same as routing only
mulmod (a, b already < m)	258,395,757	156,926,513 (1.65x)	same as routing only
div	973,193,345	126,117,010 (7.72x)	same as routing only
mod	1,063,201,232	126,183,831 (8.43x)	same as routing only
sdiv	2,033,308,510	104,132,901 (19.53x)	same as routing only
smod	2,037,919,159	103,598,333 (19.67x)	same as routing only
div by constant (x / 5)	1,555,897,335	91,790,915 (16.95x)	59,519,491 (26.14x)
mod by constant (x % 5)	1,643,949,927	91,662,819 (17.93x)	59,307,474 (27.72x)
mulmod by constant m (two-moduli contract)	1,756,336,009	293,778,256 (5.98x)	80,587,651 (21.79x)
mulmod by constant m (single-site contract)	59,308,650	288,031,112 (0.21x ❌)	75,293,850 (0.79x ❌)
mulmod chain, constant P-256 modulus (2000 ops/call)	3,273,730,193,986	272,284,595,482 (12.02x)	102,152,763,278 (32.05x)

kvpanch · 2026-07-15T12:56:42Z

  %prodl = trunc i512 %prode to i256
  %prodeh = lshr i512 %prode, 256
  %prodh = trunc i512 %prodeh to i256
-  %res = call i256 @__ulongrem(i256 %prodl, i256 %prodh, i256 %modulo)


do we still have uses of _ulongrem ?

Nope, __mulmod was its only caller, which is now using __urem512by256 instead.

Can it be removed ?

You mean _ulongrem? That is already removed.

kvpanch · 2026-07-15T13:00:20Z

Were these functions generated using some high level PL ? Perhaps, instead of keeping this ll file, we could describe algos in Rust and then convert to ll file as a part of the cargo build

Also can you please add comment with pseudo-code for each new function ?

Were these functions generated using some high level PL?

The preexisting code here was adopted from https://github.com/matter-labs/era-compiler-llvm/blob/v1.4.0/llvm/lib/Target/EraVM/eravm-stdlib.ll. So the ll changes here are handwritten (implemented and scrutinized by Claude Fable 5). It was reported along with this issue that revm uses a handwritten mulmod using Knuth Algorithm as well. What Fable has referenced precisely is "Knuth TAOCP §4.3.1 Algorithm D with 128-bit digits. The 128/64 step is Hacker's Delight §9-4 divlu". (Fable also validated the functions using millions of fuzz vectors against big-integer oracles plus our integration tests.)

Perhaps, instead of keeping this ll file, we could describe algos in Rust and then convert to ll file as a part of the cargo build

I'm not entirely sure of the feasibility of that. Perhaps having Rust emit the IR via inkwell would also be an alternative (still need to build the IR lines one-by-one though). May be worth exploring the benefits.

Also can you please add comment with pseudo-code for each new function ?

Sure!

Update: The function comments have been updated.

The preexisting code here was adopted from https://github.com/matter-labs/era-compiler-llvm/blob/v1.4.0/llvm/lib/Target/EraVM/eravm-stdlib.ll. So the ll changes here are handwritten (implemented and scrutinized by Claude Fable 5). It was reported along with this issue that revm uses a handwritten mulmod using Knuth Algorithm as well. What Fable has referenced precisely is "Knuth TAOCP §4.3.1 Algorithm D with 128-bit digits. The 128/64 step is Hacker's Delight §9-4 divlu". (Fable also validated the functions using millions of fuzz vectors against big-integer oracles plus our integration tests.)

Got it, thanks. Assuming it's taking from Matter labs and also validated, I don't need to read it

I'm not entirely sure of the feasibility of that. Perhaps having Rust emit the IR via inkwell would also be an alternative (still need to build the IR lines one-by-one though). May be worth exploring the benefits.

I meant to do something like that, i.e. describe the algorithm in Rust and compile it to LLVM IR. In this case it will be way easier to understand the code.

Just to clarify, the preexisting ll was from Matter Labs. The new/added implementation is Fable 5 generated and reviewed as described.

The Rust algorithm approach seems interesting. Yeah I agree it's not the most ideal review-wise with LLVM IR diffs. The algorithms rely on i256/i384/i512 SSA values though.

kvpanch

overall, lgtm

Divisions and modular multiplications whose divisor or modulus is a compile-time constant no longer perform any runtime division: they multiply by a precomputed reciprocal with a bounded number of conditional corrections (Barrett reduction). * `lower_wide_division` gains a second rung: an i256 `udiv`/`urem` by a non-power-of-two constant is rewritten into a generated per-constant helper (`constant_division.rs`) with floor(2^256/C) baked in and exactly one correction, ~1.5x faster per call than the routed long-division routine. * Constant-modulus mulmod is rewritten to the new stdlib routine `__mulmod_barrett` (HAC 14.42 at t = 256, two corrections, no operand pre-reduction needed) for any 256-bit non-power-of-two modulus, which covers field primes like P-256 and secp256k1; power-of-two moduli become an inline mul+mask. The rewrite runs BEFORE the main pipeline (`specialize_constant_modulus_mulmod`, behind a mem2reg/sccp/instcombine pre-pass that folds solc's NOT-form constants), because the pipeline inlines `__mulmod` into callers and no rewritable call site survives it; `lower_wide_division` repeats the sweep afterwards for moduli that only become constant during optimization. The hook is skipped at -O0 and for modules without `__mulmod` calls, leaving other contracts untouched.

Adds `make coverage` (cargo-llvm-cov over the full workspace including revive-llvm-builder), a new "Code coverage" book chapter that briefly explains how to run it, and a PR workflow that runs coverage and comments on the PR (it updates the same comment if it already exists) when the `measure code coverage` label is applied (see e.g. [this comment](#529 (comment))). Building instrumented LLVM and generating an LLVM C++ coverage report is also possible, see accompanying [PR description #575](#575) for more details. --------- Signed-off-by: Cyrill Leutwiler <[email protected]> Signed-off-by: xermicus <[email protected]> Co-authored-by: Cyrill Leutwiler <[email protected]> Co-authored-by: xermicus <[email protected]> Co-authored-by: elle-j <[email protected]> Co-authored-by: LJ <[email protected]>

The branch-free body is one ~700-instruction polkavm basic block. The O1+ inliner concatenated one copy per call site, exceeding pallet-revive's instruction limit. `noinline` caps every block at the single-body size.

elle-j added 3 commits July 14, 2026 14:54

Avoid bit-loop lowering of unsigned 256-bit div/mod/mulmod.

a97eb92

Avoid bit-loop lowering of signed 256-bit sdiv/smod.

80c0c02

Commit code size files.

46bbe4b

elle-j changed the title ~~Avoid bit-loop lowering of unsigned 256-bit div/mod/mulmod~~ Avoid bit-loop lowering of 256-bit division and remainder Jul 14, 2026

elle-j added 5 commits July 14, 2026 21:39

Keep the 256-bit division helpers outlined under newyork.

321513e

Drop the dead small-modulus path from __urem512by256.

8f74987

Early-exit trivial 256-bit divisions (dividend < divisor).

8c72ffd

Remove dead remainder updates from the division qhat corrections.

83ddee1

Cover negative small-magnitude divisors in sdiv_smod_fuzz test.

ab21035

elle-j requested review from kvpanch and xermicus July 15, 2026 08:01

kvpanch reviewed Jul 15, 2026

View reviewed changes

Add pseudo code to ll functions as per review feedback.

1e587e2

kvpanch approved these changes Jul 15, 2026

View reviewed changes

elle-j and others added 4 commits July 17, 2026 18:09

Merge remote-tracking branch 'origin/main' into lj/div-mod-mulmod

606582c

Avoid BasicBlockTooLarge from inlined __mulmod_barrett.

e7fe102

The branch-free body is one ~700-instruction polkavm basic block. The O1+ inliner concatenated one copy per call site, exceeding pallet-revive's instruction limit. `noinline` caps every block at the single-body size.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Avoid bit-loop lowering of 256-bit division and remainder#576

Avoid bit-loop lowering of 256-bit division and remainder#576
elle-j wants to merge 13 commits into
mainfrom
lj/div-mod-mulmod

elle-j commented Jul 14, 2026 •

edited

Loading

Uh oh!

kvpanch Jul 15, 2026

Uh oh!

elle-j Jul 15, 2026

Uh oh!

kvpanch Jul 15, 2026

Uh oh!

elle-j Jul 15, 2026

Uh oh!

kvpanch Jul 15, 2026

Uh oh!

elle-j Jul 15, 2026

Uh oh!

elle-j Jul 15, 2026

Uh oh!

kvpanch Jul 15, 2026

Uh oh!

elle-j Jul 15, 2026

Uh oh!

kvpanch left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

elle-j commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changes

Results

mulmod example

Dynamic cost

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvpanch left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

elle-j commented Jul 14, 2026 •

edited

Loading

`mulmod` example