Pathological compile time on multiplied modifier (`m m m m …`) with many `_;` placeholders — affects legacy and via-IR/SSA-CFG

[msooseth]

Description

A small (~3.2 KB, 126 lines) Solidity source consisting of a single modifier with many _; placeholders applied four times (m m m m) on a function causes the legacy codegen + optimizer pipeline to take 141.6 s to compile, compared to 28 ms for --via-ir --optimize — roughly a 5000× slowdown. The legacy pipeline without --optimize is also slow (10.3 s); both legacy configurations use ~1.5 GB of peak RAM, vs 19 MB for the via-IR pipelines.

Configuration	Time	Peak RSS
--via-ir	46 ms	19 MB
--via-ir --optimize	28 ms	19 MB
--via-ir --optimize --experimental --via-ssa-cfg	30 ms	19 MB
legacy (no opt)	10 313 ms	1547 MB
legacy --optimize	141 595 ms	1522 MB

Found via differential fuzzing.

Environment

• Compiler version: 0.8.35-develop.2026.5.7+commit.b83005c9.Linux.g++
• Compilation pipeline (legacy, IR, EOF): legacy is affected (both with and without --optimize); all three IR-based configurations are fast.
• Target EVM version (as per compiler settings): osaka
• Framework/IDE: solc command line
• EVM execution environment / backend / blockchain client: N/A — pure compilation
• Operating system: Linux 7.0.3-arch1-2

Steps to Reproduce

solc --bin --evm-version osaka --optimize C.sol  # ~141 s
solc --bin --evm-version osaka            C.sol  # ~10 s

Full source (126 lines): source.sol.

Inline source (click to expand)

contract C {
    uint256 public x;
    modifier m() {
        for (uint256 i; i < 10; i++) {         _;
            return;
            for ( i; i < 10; i++) {
            {
            {
            assembly {
                for { let a := 0} lt(a,1) { a := add(a, 1) } { continue let b := 42 }
                for { let a := 0} lt(a,1) { a := add(a, 1) } { continue let b := 42 }
            }
            }
            return;
            for (uint256 i; i < 10; i++) {
                _;
                uint t;
                uint8 x = 0xff;
                for (uint256 i; i < 10; i++) { _; return; ++x; }
            }
            }
            { /* more nested for/_;/return/assembly … */ }
            /* 12 `_;` placeholders in total in this modifier body, interleaved
               with `return;`, deeply-nested for-loops and inline assembly */
            ...
        }
    }

    function f() public m  m m m returns (uint) {  // modifier applied 4 times
        for (uint256 i = 0; i < 10; i++) {
            ++x;
        }
    }
}

The full text is in the gist. The salient feature is that modifier m contains 12 _; placeholder sites, and is applied four times on f(). In the legacy codegen each placeholder site inlines the next modifier's body, so the chain m m m m f materialises on the order of 12⁴ ≈ 2 × 10⁴ inlined copies of the inner code path, embedded inside heavily-nested control-flow (nested for-loops, inline assembly with continue/dead-store patterns, and many return; statements that the legacy frontend leaves in place).

Nature of the slowdown

The slowdown is a legacy-codegen compile-time issue, not a runtime / output bug. All five configurations produce bytecode successfully. The via-IR pipeline (with or without optimizer, and with or without SSA-CFG) handles this source in under 50 ms; only the legacy pipeline is slow:

1. Without --optimize, legacy already takes ~10 s and 1.5 GB of RAM. Even the no-optimize legacy build runs the peephole optimiser and JumpdestRemover, which dominate.
2. With --optimize, legacy jumps to ~142 s. The added cost is overwhelmingly in evmasm::BlockDeduplicator::deduplicate() on the assembled EVM code.

The Solidity feature driving the blow-up is modifier application multiplied across _; placeholders: m m m m on f, where m contains 12 _;, produces a multiplicative expansion of the inner body inside the legacy ContractCompiler::appendModifierOrFunctionCode chain. Each instance generates structurally similar EVM blocks, feeding the assembly optimiser an enormous list of basic blocks.

Relevant perf data

Full perf top-50 reports and flamegraphs are in the attached gist; the salient parts:

legacy --optimize — 141.6 s (flamegraph, perf top50)

93.09%  evmasm::Assembly::optimiseInternal
65.99%  evmasm::BlockDeduplicator::deduplicate
57.02% 25.19%  BlockDeduplicator::deduplicate lambda                  ← 25% self
17.31%  9.66%  BlockDeduplicator::BlockIterator::operator++           ← ~10% self
 9.80%  9.79%  evmasm::AssemblyItem::instruction                      ← ~10% self
 8.68%  CommonSubexpressionEliminator::getOptimizedItems
 7.91%  5.98%  evmasm::SemanticInformation::altersControlFlow         ← ~6% self
 7.06%  PeepholeOptimiser::optimise

BlockDeduplicator::deduplicate alone accounts for ~66% of the entire 141 s run, with ~25% self-time in its per-pair comparison lambda.

legacy (no opt) — 10.3 s (flamegraph, perf top50)

84.49%  evmasm::Assembly::optimiseInternal     ← runs even without --optimize
66.42%  6.41%   PeepholeOptimiser::optimise
50.93% 16.78%   applyMethods<PushPop, OpPop, OpStop, …>     ← ~17% self
14.56%  9.32%   AssemblyItem::operator==(Instruction)        ← ~9% self
14.35%  3.64%   JumpdestRemover::optimise
13.76% 13.59%   std::vector<AssemblyItem>::push_back
 9.13%  9.12%   evmasm::AssemblyItem::instruction
 7.50%  7.43%   AssemblyItem::bytesRequired

Even without --optimize, the legacy assembler still runs a peephole pass and JumpdestRemover; together they dominate the 10 s run — the input EVM assembly is simply very large.

via-IR pipelines — under 50 ms each

All three via-IR configurations finish in ~30–46 ms and use 19 MB. Profiles are essentially flat (see attached). The IR pipeline either avoids producing the same item explosion (dead-code / reachability done earlier) or handles it without quadratic blow-up.

Potential reasons

A few observations, presented without proposing a fix:

• BlockDeduplicator::deduplicate is ~66% of the legacy --optimize run, with 25% self-time in the per-pair comparison lambda and 10% self in the iterator advance. The dominant frames are consistent with roughly quadratic block-pair comparison over a very long block list.

• Modifier-inlining multiplier. m has 12 _; sites, and f is decorated with m m m m. In the legacy ContractCompiler pipeline each _; inlines the next modifier's body in full, so the chain produces on the order of 12⁴ ≈ 2 × 10⁴ copies of the inner body — plus the modifier-body assembly itself replicated similarly. The legacy frontend does not drop post-return; regions before emitting EVM, so dead branches still reach the optimizer.

• Even without --optimize (legacy, 10 s), peephole + JumpdestRemover dominate, with applyMethods<…> at 17% self and AssemblyItem::operator== at 9% self. The size of the emitted item vector — driven by the modifier-inlining blow-up above — appears to be the underlying driver across both legacy configurations.

• All three via-IR pipelines are unaffected (28–46 ms, 19 MB). The two codegens scale very differently on modifier-heavy / dead-code-heavy inputs (contrast with e.g. Slow compilation under via-ir & SSA-CFG on deeply nested try/catch #16697, where via-IR is the slow path).

Attachments

All artefacts are in a single gist: https://gist.github.com/msooseth/b221f0ac40d878147f1209370050558a

• source.sol — the full reproducer (126 lines)
• noOpt_viaIR=false.perf_top50.txt, opt_viaIR=false.perf_top50.txt — slow legacy profiles
• noOpt_viaIR=true.perf_top50.txt, opt_viaIR=true.perf_top50.txt, opt_ssaCFG.perf_top50.txt — fast via-IR reference profiles
• corresponding *.flamegraph.svg files for each configuration

[msooseth]

Found another reproducer that's more extreme than the original report: a 48-line / ~1.5 KB Solidity file that pushes solc --bin --evm-version osaka --optimize past 126 s without finishing (perf sampling stopped before solc did). Same hotspot fingerprint as this issue — BlockDeduplicator::deduplicate() and friends are at the top — so I'm posting it here rather than filing a duplicate. Cross-ref: PR #16684 looks like the fix.

Repro

solc --bin --evm-version osaka --optimize source.sol

Compiler: 0.8.36-develop.2026.5.18+commit.090bc8ff.mod.Linux.g++, target osaka.

Full source: source.sol. It's a contract with a single modifier m() containing many _; placeholders interleaved with return;, dead uint a = uint256(0)/uint256(0); statements, and 27+ nested infinite for (;;) loops; the modifier is then applied six times (m m m m m m) on f(). Same modifier-multiplied pattern as #16699 but with even more nested empty for-loops, which seem to make the BlockDeduplicator pathologically slower.

Inline source (click to expand)

Details

contract C {
    uint256 public x;
    modifier m() {
        for (uint256 i = 0; i < 10; i++) {
            _;
            ++x;
            return;
            uint256 a = uint256(0) / uint256(0); for (;;) for (;;) for (;;) for (;;) for (;;)  for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) {
            _;
            abi.encodeWithSelector(0x12345678, abi.encodeWithSelector(0x12345678, 0x12345678));
            return;
            uint256 a = uint256(0) / uint256(0); for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) {} for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) for (;;)  for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) for (;;) {
            _;
            ++x;
            return;
            // … further nested for(;;)/_;/return; chains, see gist …
        }
    }

    function f() public m m m m m m returns (uint) {
        for (uint256 i = 0; i < 10; i++) {
            ++x;
        }
    }
}

perf data

Sampled with perf record -F 4000 -g -- solc --bin --evm-version osaka --optimize source.sol on Ryzen 7 PRO 5850U / Linux 7.0.5. The compile was killed after the 126.7 s sample window; it had not produced any bytecode.

Total samples: 497K, event count: 440 G cycles.

Top symbols (self %)

Self %	Symbol
17.56%	BlockDeduplicator::deduplicate()::lambda(size_t,size_t) (the comparator)
10.66%	AssemblyItem::instruction() const
8.59%	BlockDeduplicator::BlockIterator::operator++()
6.84%	PeepholeOptimiser::applyMethods<…> (one giant inlined template)
6.22%	std::vector<AssemblyItem>::push_back
4.36%	SemanticInformation::altersControlFlow(AssemblyItem const&)
3.61%	AssemblyItem::splitForeignPushTag()
3.25%	AssemblyItem::operator==(Instruction)
3.08%	AssemblyItem::pushTag()
2.70%	PeepholeOptimiser::optimise()
2.57%	Inliner::optimise()
2.33%	BlockDeduplicator::deduplicate() (the outer body)
1.38%	JumpdestRemover::optimise()

Cumulative (children) view

Children %	Symbol
88.15%	Assembly::optimise / optimiseInternal
48.32%	BlockDeduplicator::deduplicate()
42.77%	…of which the comparator lambda + its callees
25.97%	PeepholeOptimiser::optimise()
14.41%	BlockDeduplicator::BlockIterator::operator++()
7.27%	Inliner::optimise()
4.47%	JumpdestRemover::optimise()

Full top-50 list and full children view are in the gist: perf_top50.txt, perf_children50.txt.

Why this is worse than the original repro

The pattern matches the original m m m m + many-_; shape, but two things compound:

1. More modifier applications (m m m m m m vs. m m m m), which multiplies the inlined-body count and thus the number of basic blocks fed to the optimiser.
2. Many empty for (;;) chains. Each becomes a tiny (often single-JUMP-to-self) basic block; legacy codegen emits structurally near-identical blocks for each one, which is exactly the pathological input shape for BlockDeduplicator's std::set + lexicographical comparator (each insertion is O(block_size · log N) and each comparison can walk most of the items vector). The outer optimiseInternal loop reruns the whole pipeline as long as any pass reports a change, so the quadratic cost is paid many times.

So this looks like the same root cause as #16699 — and PR #16684 (unordered_set + cached hash, O(block_size) amortized lookup) should make it go away. Happy to retest once that PR lands if useful.

[msooseth]

Same source shape also hangs --via-ir --optimize and --experimental --via-ssa-cfg

Worth widening the scope of this report: with a different (much smaller) body for the same m m m m … shape, the via-IR + optimizer and SSA-CFG pipelines are the ones that hang, while legacy stays fast.

Reproducer (446 bytes)

Also available as a gist: source.sol.

contract C {
    uint256 public x;
    modifier m() {
        for (uint256 i = 0; ; ((-(2**159) + 10159) / 128 / 0x100000000 / 2)) {
            _;
            _;
            ++x;
            ++x;
            _;
            revert("abc");
            return;
        }
    }

    function f() public m m m m m m m m returns (uint) {
        {
            ++x;
            return 42;
        }
    }
}

Found via AFL fuzzing of solc. Three _; placeholders in the modifier body, applied 8× on f().

Measurements

solc 0.8.36-develop.2026.5.18+commit.090bc8ff, Ryzen 9 3900, Linux 7.0.5:

Configuration	Wall time
--via-ir	0.02 s
legacy (no opt)	1.20 s
legacy --optimize	3.11 s
--via-ir --optimize	>120 s (killed)
--experimental --via-ssa-cfg --optimize	>120 s (killed)

So the affected pipelines are the opposite of the ones in the original report: legacy completes in seconds, while --via-ir --optimize and --via-ssa-cfg don't terminate within a 2-minute cap. --via-ir without the optimizer is the only IR-based config that's fast.