optimizer: gas-gap analysis for top 30 semantic tests and Uniswap v4

[leonardoalt]

Gas optimization gap report

Date: 2026-07-20

Compiler revision: 262c111345fd87db3570fd3986a38c9094ffcf89

Solidity corpus revision: 902f848958ff94c10492f546476bd23fd989fbb1

Reference compiler: solc 0.8.35, EVM version osaka

Scope and method

This report analyzes the gas suites that compare real Solidity contracts through
the two optimized pipelines:

ours: Solidity --solc --ir--> unoptimized Yul
      --verified optimizerPipelineObject--> optimized Yul
      --verified backend--> EVM

solc: Solidity --optimize --via-ir--> optimized Yul --> EVM

The primary ranking is by absolute excess execution gas, ours - solc, across:

• test/solidity-semantic-gas-baseline.txt;
• test/solidity-gas-baseline.txt; and
• test/uniswap-v4-gas-baseline.txt.

All global top-30 rows are in semanticTests; repeated loop scenarios make their
absolute gaps much larger than the microbenchmarks. Uniswap and gasTests are
therefore analyzed separately rather than omitted.

The checked-in numbers were remeasured with a freshly rebuilt
checkSolidityGas. Every selected semantic row, every compiling Uniswap row,
and all 12 gasTests rows reproduced exactly.

For every top-30 and Uniswap fixture I also dumped:

1. solc's unoptimized --ir (the common input);
2. the Yul AST after this repository's production verified optimizer; and
3. solc's --ir-optimized --optimize --via-ir output.

The defs/calls columns below count named Yul function definitions and static
call sites to those defined functions. They are structural indicators, not
dynamic call counts. They are useful here because retained Yul calls become the
compiler's explicit return-address/jump calling convention.

Executive summary

• The semantic suite totals 135,139,424 gas ours vs 96,695,611 solc, a
  38,443,813 gas gap (1.398x). Ours is more expensive on 842 of 846
  comparable fixtures; four are equal and none is cheaper.
• The top 30 account for 36,046,560 gas, or 93.8% of the semantic gap.
  The top three dynamic-array loop fixtures alone account for 29,391,099 gas
  (76.5%).
• On the top 30, the common unoptimized IR contains 3,482 function definitions
  and 7,213 static calls. Our pipeline reduces this to 3,358 definitions / 5,799
  calls; solc reduces it to 227 / 676. The dominant difference is therefore
  not missed local constant folding. It is missing interprocedural
  inlining/specialization followed by propagation and dead-code removal.
• Compiling Uniswap fixtures total 30,658 gas ours vs 7,365 solc (4.16x).
  Our optimized Yul still has 243 definitions / 350 calls across those six
  contracts; solc has 5 / 8.
• The other five Uniswap fixtures do not produce gas rows. FullMath,
  SqrtPriceMath, SwapMath, TickBitmap, and TickMath still fail the
  backend's DUP16/SWAP16 reach check. Our optimized Yul retains 481 functions,
  899 call sites, and many live temporaries across them. This is both an
  optimization problem and a stack-allocation problem.
• The immediate high-value work is a scoped dataflow pass (safe copy/constant
  propagation plus general DCE), stack-pressure-aware helper inlining, loop
  optimization, and stack compression/spilling. Backend peepholes are secondary
  for these execution-gas measurements.

The 30 largest absolute gaps

ours defs/calls and solc defs/calls describe the respective optimized Yul.

#	Fixture	Ours	solc	Excess	Ratio	Ours defs/calls	solc defs/calls
1	array/array_storage_length_access.sol	13,066,985	1,306,640	11,760,345	10.00x	32/29	0/0
2	array/array_storage_push_empty_length_address.sol	13,395,747	2,139,347	11,256,400	6.26x	45/45	1/2
3	array/array_storage_push_pop.sol	20,402,922	14,028,568	6,374,354	1.45x	43/41	1/2
4	storageLayoutSpecifier/dynamic_array_storage_end.sol	26,392,544	25,142,559	1,249,985	1.05x	53/61	1/3
5	storageLayoutSpecifier/mapping_storage_end.sol	25,638,980	24,503,311	1,135,669	1.05x	36/38	0/0
6	array/array_storage_index_zeroed_test.sol	8,480,879	7,424,367	1,056,512	1.14x	52/73	8/18
7	array/copying/bytes_storage_to_storage.sol	1,592,768	835,859	756,909	1.91x	76/113	6/17
8	array/array_storage_index_boundary_test.sol	938,373	212,135	726,238	4.42x	43/45	1/3
9	array/array_storage_index_access.sol	7,360,907	6,816,025	544,882	1.08x	50/53	1/4
10	array/array_memory_index_access.sol	371,681	109,723	261,958	3.39x	55/72	3/8
11	events/event_indexed_string.sol	485,797	311,724	174,073	1.56x	74/87	2/5
12	array/byte_array_storage_layout.sol	185,254	131,729	53,525	1.41x	57/87	3/8
13	array/pop/byte_array_pop_long_storage_empty_garbage_ref.sol	173,105	120,974	52,131	1.43x	48/59	11/14
14	storage/storage_boundary_packed_array.sol	133,140	81,069	52,071	1.64x	83/102	1/2
15	storage/storage_packed_array_copy.sol	115,428	64,188	51,240	1.80x	135/158	1/2
16	viaYul/detect_mul_overflow_signed.sol	67,599	20,469	47,130	3.30x	40/58	0/0
17	array/copying/nested_array_of_structs_memory_to_storage.sol	594,133	547,431	46,702	1.09x	281/543	16/56
18	storage/storage_boundary_array_copy.sol	229,616	185,548	44,068	1.24x	145/179	3/8
19	array/invalid_encoding_for_storage_byte_array.sol	659,012	616,496	42,516	1.07x	148/265	10/48
20	array/copying/nested_array_element_storage_to_storage.sol	452,750	411,659	41,091	1.10x	308/651	43/140
21	operators/userDefined/all_possible_operators.sol	39,567	426	39,141	92.88x	69/345	1/3
22	array/copying/nested_array_of_structs_calldata_to_storage.sol	576,864	538,435	38,429	1.07x	281/498	16/56
23	viaYul/exp_various.sol	46,145	13,388	32,757	3.45x	32/44	2/2
24	functionCall/calling_other_functions.sol	38,740	6,030	32,710	6.42x	37/46	2/4
25	array/copying/nested_array_element_storage_to_memory.sol	125,751	94,161	31,590	1.34x	433/792	36/115
26	viaYul/exp_neg.sol	80,962	51,077	29,885	1.59x	26/28	1/1
27	abicoder/calldataDecoding/array/calldata_nested_array_reencode_v2.sol	56,106	27,162	28,944	2.07x	132/186	6/24
28	array/copying/array_to_mapping.sol	212,773	184,091	28,682	1.16x	239/453	16/39
29	array/copying/nested_array_of_structs_storage_to_storage.sol	308,801	280,371	28,430	1.10x	202/425	26/68
30	viaYul/unary_operations.sol	49,420	21,227	28,193	2.33x	103/223	9/24

Per-fixture diagnosis

Rows	Dominant difference in optimized Yul
1-3	Dynamic-array push/pop loops. Ours executes generic length, bounds, index, zeroing, readback, cleanup, and panic helpers on every iteration. solc inlines and specializes these to direct sload/sstore, comparisons, and the required panic branches.
4-6, 9	Thousand-iteration or multi-loop storage tests. The remaining percentage is smaller because storage dominates, but repeated checked-increment, conversion, array/mapping address, and cleanup calls still add 0.5-1.25M gas per fixture. Missing LICM and induction-variable simplification amplify the cost.
7, 12-15	Dynamic bytes and packed storage. Ours retains generic short/long byte-array branches, masks, extract/update helpers, and copy loops. solc specializes element width/layout and removes redundant cleanup/readback paths.
8, 10	Boundary/index microbenchmarks. Generic allocation, index-access, cleanup, and panic helpers dominate what solc reduces to direct bounds checks and address arithmetic.
11	Indexed dynamic event data. Ours retains ABI/memory-array helper layers around copying, hashing, and logging; solc joins the encoding/copy path and keeps only a few helpers.
16, 23, 26, 30	Checked arithmetic, exponentiation, and unary operations. Ours retains cleanup/conversion and checked-operation functions around each call. solc inlines the checks and propagates widths/values through them.
17-20, 22, 25, 27-29	Nested array/struct ABI and storage copies. These have the largest Yul helper graphs: decoders, allocators, indexers, element converters, copy loops, and encoders. solc specializes by concrete type and joins loops/expressions; ours preserves most generic layers.
21	Interprocedural constant case. The Solidity body is a sequence of assertions over constants and user-defined operator wrappers. solc resolves nearly everything at compile time; ours still executes 345 static helper call sites spanning constants, cleanup, conversions, wrappers, and assertions. This is the clearest evidence for general inlining + propagation + DCE.
24	Collatz loop calling evenStep/oddStep. solc inlines/specializes the small arithmetic functions. Ours retains the general Yul function-call protocol on every loop iteration.

What the optimized Yul actually looks like

The largest fixture is representative. Our optimized loop is still expressed
through generic Solidity-generated helpers (abridged):

for { } 1 { } {
  let expr := array_length_t_array$_t_uint256_$dyn_storage(0)
  if iszero(lt(expr, var_len)) { break }
  let slot, offset := array_push_zero_t_array$_t_uint256_$dyn_storage_ptr(0)
  let ignored := read_from_storage_split_dynamic_t_uint256(slot, offset)
}

Those helpers call further helpers. For example, array_push_zero... calls the
array-length and index-access functions and a panic function before returning two
values through the compiler's stack calling convention.

solc's optimized Yul has no function definitions in this contract and emits the
operations directly in the loop (abridged):

for { } 1 { } {
  let oldLen := sload(0)
  if iszero(lt(oldLen, value)) { break }
  if iszero(lt(oldLen, 0x10000000000000000)) {
    mstore(0, shl(224, 0x4e487b71))
    mstore(4, 0x41)
    revert(0, 0x24)
  }
  let newLen := add(oldLen, 1)
  sstore(0, newLen)
  if iszero(lt(oldLen, newLen)) {
    mstore(0, shl(224, 0x4e487b71))
    mstore(4, 0x32)
    revert(0, 0x24)
  }
  mstore(0, 0)
}

The same pattern appears in the arithmetic cases: our optimizer can inline a
single-assignment flat pure helper, but not a helper containing checks, branches,
multiple assignments, nested calls, or multi-value results. solc inlines those
helpers, specializes them with argument facts, folds the exposed expressions,
and deletes the now-unused scaffolding.

Uniswap v4

Compiling fixtures

Fixture	Calls replayed	Ours	solc	Excess	Ratio	Ours defs/calls	solc defs/calls	Main retained work
BitMath.sol	6	6,186	1,836	4,350	3.37x	27/32	0/0	Wrapper calls, result zeroing, ABI helpers, and the MSB/LSB function boundary; solc places the assembly directly in each selector arm.
LPFeeLibrary.sol	5	6,420	1,294	5,126	4.96x	55/89	4/5	uint24 cleanup, flag predicates, validation, custom-revert helpers, and wrapper calls.
LiquidityMath.sol	3	3,165	831	2,334	3.81x	22/23	0/0	Signed/unsigned conversions, checked add/sub, cleanup, ABI, and wrapper layers.
ProtocolFeeLibrary.sol	4	4,478	1,091	3,387	4.10x	48/69	1/3	Width cleanup, constant wrappers, checked arithmetic, and nested library calls.
SafeCast.sol	6	6,509	1,545	4,964	4.21x	68/105	0/0	Conversion/cleanup chains and custom-revert wrappers remain as calls; solc reduces each selector to a direct mask/signextend/check sequence.
UnsafeMath.sol	4	3,900	768	3,132	5.08x	23/32	0/0	divRoundingUp and mulDiv wrapper/ABI/helper call protocol instead of direct arithmetic.

The Uniswap total is 30,658 vs 7,365, an excess of 23,293 gas. These are
small pure-library calls, so there is little expensive state work to hide call
overhead; missing interprocedural optimization is exposed directly.

Rejected fixtures: the more important Uniswap result

Fixture	Our optimized defs/calls	solc optimized defs/calls	Why it still fails
FullMath.sol	34/71	3/7	mulDiv retains long chains of zero-initialized and reassigned temporaries plus wrapping helpers; a needed local becomes deeper than the classic stack instructions can reach.
SqrtPriceMath.sol	79/193	19/62	Nested FullMath, cast, branch, and rounding helpers preserve too many simultaneous values.
SwapMath.sol	80/208	27/78	The large multi-result computeSwapStep path combines the SqrtPrice/FullMath graph with many live branch results.
TickBitmap.sol	111/169	1/2	Signed-width conversion/cleanup and bit-math helper chains leave many stack locals despite solc reducing the runtime almost completely.
TickMath.sol	177/258	4/22	Long sequences of shifts, masks, constants, and signed conversions retain hundreds of temporary bindings and calls.

This is not solved by inlining alone: indiscriminate inlining can increase live
stack pressure. The necessary unit is inlining/specialization plus propagation,
DCE, and stack-aware scheduling, with spilling or a stack-compression fallback
when the result still exceeds depth 16.

Other Solidity gasTests

The 12 rows reproduce at 396,019 ours vs 336,827 solc (1.176x, +59,192).
The _optimised fixture pairs produce identical source sections in this harness,
so the distinct gaps are:

Fixture(s)	Excess per row	Ratio	Optimized-Yul difference
dispatch_large*	15,925	1.21x	Ours 107 defs/287 calls vs solc 20/37; dispatch and ABI helper specialization dominate.
dispatch_medium*	6,037	1.15x	Ours 75/127 vs solc 2/13.
exp*	2,800	4.61x	Ours 39/46 vs solc 0/0; checked exponent and cleanup helpers dominate.
abiv2*	2,224	1.32x	Ours 157/302 vs solc 18/53; nested ABI decoding/encoding and copy helpers dominate.
dispatch_small*	1,679	1.06x	Ours 50/57 vs solc 1/2.
storage_costs.sol	1,469	1.05x	Repeated generic storage/cleanup helpers around intrinsically expensive storage operations.
data_storage.sol	393	2.95x	A tiny path where helper and ABI overhead is most of the execution.

Main missing optimizations

1. General interprocedural inlining and specialization

Current InlineHelpers handles only a narrow Core shape: one assignment of a
flat pure expression, with flat value arguments. The object path is further
restricted to variable-only classification so that layout resolution cannot
change whether a call is inlined.

Missing cases visible throughout the top 30 and Uniswap are:

• multi-statement helpers;
• helpers containing a guard or panic/revert branch;
• nested helper calls;
• multi-result helpers;
• helpers called with literals on the object path;
• single-use functions and wrapper functions; and
• specialization by known widths, masks, storage layout, or constant arguments.

Inlining should be driven by a live-stack/size budget, not only AST size. It
should process the lexical call graph by SCC, decline recursive edges, and rerun
propagation and pruning on the specialized body.

2. Full scoped propagation and dead-code elimination

Production Propagate intentionally creates literal facts only. Copy facts are
proved but disabled because substituting an older variable made dispatch_*
locals deeper and caused DUP16 failures. DeadLits removes only dead literal
bindings.

Still missing:

• depth-aware copy propagation;
• propagation through assignments, function arguments/results, and branch joins;
• dead pure lets with nonliteral right-hand sides;
• dead assignments and overwritten values;
• dead function definitions;
• branch pruning after interprocedural propagation; and
• removal of redundant zero-initialization/return-slot scaffolding.

An intrinsically scoped Core/ANF pass is the cleanest way to prove the required
well-boundness facts while retaining the strong Optimizer.Pass contract. Using
the weaker observational pass contract for arbitrary DCE would move the audited
specification boundary and therefore requires human approval; it is not needed
if the scoped pass can prove exact block equivalence.

3. Loop optimization

Rows 1-10 dominate absolute gas because a modest body overhead repeats hundreds
or thousands of times. Needed transformations include:

• loop-invariant code motion;
• induction-variable recognition and checked-increment simplification;
• caching/reusing array length, base slot, keccak-derived data area, masks, and
  element width when sound;
• eliminating unused push-result readbacks;
• specializing generic array/bytes helpers into the loop body; and
• loop fusion/joining for decode-copy-encode and storage-copy paths.

The current simplifier also leaves for initializers unchanged because their
scope/hoisting congruence has not yet been proved. That is a smaller but concrete
coverage hole.

4. Stack compression or spilling

The backend correctly rejects reads/stores deeper than DUP16/SWAP16. The five
heavy Uniswap fixtures show that source optimization alone is not yet a reliable
way to stay below the limit.

A stack-allocation pass should shorten live ranges, rematerialize cheap literals
and expressions, reorder independent computations, and spill only as a fallback.
This should be designed together with inlining: the profitability metric must
include maximum live depth. It is higher priority than adding more local rewrite
rules because it unlocks currently unsupported production programs.

5. Richer expression simplification and CSE

The current rule engine folds flat all-literal pure operations and a small set of
neutral identities. The dumps still contain:

• nested cleanup/conversion chains;
• repeated masks, shifts, sign extensions, and boolean normalization;
• repeated bounds/address expressions;
• redundant iszero layers in condition position;
• duplicate pure calculations; and
• constant assertions only exposed after helper inlining.

Add proved rules behind the existing Core rule interface, then add pure-expression
CSE with explicit invalidation for memory/storage reads.

6. ABI, array-copy, and memory specialization

The nested-copy rows have hundreds of decoder, allocator, accessor, converter,
copy, and encoder call sites. A typed Core representation can specialize these by
concrete element width and location, join adjacent loops, reuse allocation facts,
and remove encode/decode round trips whose intermediate value does not escape.

7. Backend work is secondary for this benchmark

The verified function convention has real overhead: code-address pushes, return
slots, jumps, rotations, and dynamic return jumps. Eliminating Yul calls removes
that overhead at its source. Later Asm-level jump threading or stack peepholes may
help, but they cannot explain the 4-10x loop and Uniswap gaps.

Shorter PUSH encodings would mostly improve bytecode/deployment size, not the
call execution gas summed by this harness, and would disrupt the repository's
fixed-width location proofs. It is not the appropriate first response to these
results.

Recommended implementation order

1. Unlock the Uniswap compile frontier: scoped use/liveness analysis,
   nonliteral DCE, stack-depth-aware copy propagation, and a stack compressor or
   spill fallback. Track all five currently rejected fixtures as acceptance
   targets.
2. Add stack-aware general helper inlining/specialization: guards,
   multi-statement bodies, nested calls, and multi-result helpers; compose it
   immediately with propagation and DCE.
3. Optimize the dominant loops: start with the dynamic-array push/pop family
   (rows 1-3), then storage index/address helpers (rows 4-10), measuring gas per
   iteration as well as fixture totals.
4. Expand the Core rule/dataflow engine: conversions, masks, boolean facts,
   bounds facts, branch joins, CSE, and dead assignments.
5. Specialize ABI/array copy graphs: target rows 7, 11-15, 17-20, 22, and
   25-29.
6. Only then pursue backend peepholes, with Phase A/Phase B simulation and
   fixed-width location invariants preserved.

Useful acceptance metrics for each optimizer change are:

• total and per-fixture execution gas;
• maximum live stack depth and number of formerly rejected fixtures;
• reachable named-call sites after optimization (not just total AST size);
• optimized bytecode size and deployment gas as separate metrics; and
• zero regressions in all existing behavioral differentials and gas ceilings.

Reproduction

lake build checkSolidityGas

.lake/build/bin/checkSolidityGas \
  test/uniswap-v4 test/uniswap-v4-gas-baseline.txt \
  "$(svm which 0.8.35)" 0.8.35 \
  --known=test/uniswap-v4-known-compile-failures.txt

.lake/build/bin/checkSolidityGas \
  /tmp/solidity/test/libsolidity/gasTests \
  test/solidity-gas-baseline.txt \
  "$(svm which 0.8.35)" 0.8.35

For Yul inspection, the reference sides are produced with solc --ir and
solc --ir-optimized --optimize --via-ir --evm-version osaka. The repository
side is the parsed/desugared object after
Optimizer.optimizerPipelineObject, printed with YulParser.printObjC.

[leonardoalt]

The depth-aware copy-propagation and scoped-DCE follow-up recommendations are tracked in #64. Statement-level call inlining is proposed in PR #63.

[leonardoalt]

Post-#63 evaluation at main (6d3cc0a): InlineCalls closed 3,354,775 of the 38.44M semantic gap (8.7%); the top-3 dynamic-array loop rows still hold 27.9M (79%) of the remaining 35.09M. Dumps show the residual costs are (a) copy/rename scaffolding, (b) the add(f(…),0) fence keeping the read_from_storage chains expression-level, and (c) — newly diagnosed — InlineCalls capture-condition name collisions (value/slot/offset reuse) blocking the whole helper chain in rows 1–3.

PR #67 (closes #64) attacks (a) and (b): depth-gated copy propagation + DeadPure DCE + open-operand identities close a further 1,198,198 gas on the semantic suite (769/846 rows), −2,782 on gasTests, −1,875 on Uniswap, and 11 semantic fixtures newly produce gas rows. (c) — call-site freshening — is the highest-leverage follow-up for the loop rows; the five DUP16-rejected Uniswap fixtures still need stack compression (they fail unoptimized too).

[leonardoalt]

Fresh evaluation at current main (d0bae21; Solidity corpus 902f848; solc 0.8.35, Osaka). I rebuilt checkSolidityGas and reran the full semantic suite, all 12 gasTests, the complete Uniswap suite, and fresh optimized-Yul dumps.

Because smart stack layout added many comparable fixtures, there are now two useful views of the semantic result:

• On the issue's original 846-fixture set, ours is now 106,681,225 vs 96,695,611 solc, a 9,985,614 gap (1.1033x). That is −28,458,199 gas / 74.0% of the original 38.44M gap closed. Relative to the post-feat(optimizer): InlineCalls — statement-level inlining of call-free helpers #63 update at 6d3cc0a, another 25,103,424 gas has been removed, closing 71.5% of the gap that remained then.
• Current coverage is 1,134 comparable semantic rows (+288). Across that larger set the fresh total is 129,713,494 vs 115,963,465, a 13,750,029 gap (1.1186x): 1,129 rows are more expensive, four equal, and one cheaper. The current top 30 account for 10.17M (74.0%) of this gap, so it is materially less concentrated than the original report.
• The full rerun had zero regressions against the checked-in ceilings, but 98 rows beat those ceilings by a further 196,904 gas. This is a merge-composition gain not represented in the current baseline and should be tightened on the next gas re-pin.

The former top-three loop rows changed as follows:

Fixture	Post-#63 ours	Current ours	solc	Current excess	Gain since post-#63
array_storage_length_access.sol	12,799,622	2,553,632	1,306,640	1,246,992	−10,245,990
array_storage_push_empty_length_address.sol	13,124,746	2,657,601	2,139,347	518,254	−10,467,145
array_storage_push_pop.sol	19,433,167	17,124,080	14,028,568	3,095,512	−2,309,087

Together they fell from a 27,882,980 post-#63 gap to 4,860,758 (82.6% closed). They now hold 48.7% of the remaining gap on the original common set, or 35.4% of the larger current gap. array_storage_push_pop is still #1; length access is #2; push-empty is now #5.

The fresh dumps confirm that FreshenCalls, HoistCalls, InlineCalls, DeadResults, and the two storage-forwarding steps did what the previous analysis predicted. Static calls in the three optimized objects fell from 29/45/41 to 4/9/9 (definitions remain 32/45/43; solc is 0/1/1 defs and 0/2/2 calls). In particular, the unused read-from-storage chain is gone and the just-written array length is forwarded through the inlined scopes.

The residual is now more specific:

• The push loops still materialize unused slot, offset results and compute the data-area keccak256, even when the source discards the push result. This wants liveness-aware multi-result/result-slot pruning or specialization of the effect-only push path.
• The pop loop still calls array_pop, whose chain reaches storage_set_to_zero / update_storage_value; the named update_byte_slice_dynamic32(...) nested under sstore(...) remains the inlining fence. A profitability-controlled right-to-left argument split (or a storage-update-specific specialization) is still the clearest next attack. The previously measured unconditional splitter's small regressions explain why this needs a cost/depth gate.

Uniswap also moved substantially:

• The original six compiling fixtures are now 23,385 vs 7,365 (3.18x, gap 16,020), −7,273 gas / 31.2% of their original gap closed.
• Smart stack layout makes FullMath, SqrtPriceMath, TickBitmap, and TickMath compile, so coverage is now 10/11; only SwapMath.sol remains beyond classic DUP16/SWAP16 reach.
• Across all ten comparable fixtures the fresh result is 997,390 vs 349,360 (2.85x). TickMath alone contributes 600,483, or 92.7% of the Uniswap gap; its static calls are down from 258 to 45, but the repeated getSqrtPriceAtTick / getTickAtSqrtPrice sweeps still execute large cleanup-heavy arithmetic bodies. This is now the main Uniswap gas target, while SwapMath remains the acceptance target.
• The isolated rerun also found TickBitmap at 64,824, 984 below its checked-in 65,808 ceiling, confirming the cross-pass baseline staleness noted above.

Finally, gasTests reproduce at 370,515 vs 336,827 (1.1000x, gap 33,688), −25,504 gas / 43.1% of the issue's original gap closed.

So the highest-leverage next order is now: (1) unused multi-result/effect-only specialization in the array push path, (2) cost- and stack-aware argument normalization plus deeper inlining for the pop/update chain, (3) TickMath loop/arithmetic cleanup and CSE, and (4) another smart-layout/spill step to admit SwapMath. Broad call inlining is no longer merely a hypothesis: the measurements show it and its cleanup/dataflow follow-ups account for most of the 28.46M semantic improvement.

[leonardoalt]

Current optimizer/gas state (2026-07-25)

I reran all four real-Solidity gas suites at 794a2ec7220fd148dac8318cce06f08e248c87ad, Solidity corpus 902f848958ff94c10492f546476bd23fd989fbb1, solc 0.8.35, Osaka. I also compared solc's unoptimized IR, our current normalized + six-round production pipeline output, and solc's optimized IR for representative leaders.

First: the semantic baseline is stale

The fresh semantic run has 1,237 comparable scenarios, versus 1,134 pinned rows: 118 unpinned and 15 stale. Four fixtures have declared calls that now execute but fail behavioral comparison:

• array_storage_length_access
• array_storage_push_empty_length_address
• array_storage_push_pop
• various/create_random

The first three were the headline gas wins in the preceding update, so I have excluded them from the current ranking rather than reporting stale numbers as successes. These are priority-zero correctness investigations.

The other 11 stale rows are incomplete parsing of Solidity // ---- call specifications (fixed-fee registrar, account, fixed-bytes library call, nonpayable circumvention, alignment, uint-to-fixed-bytes, external-function-to-address, transient-state address, function address, function selector, and unary fixed-bytes). That is harness coverage, not optimizer performance. We should extend SolTest parsing and then remeasure; neither class should be silently re-pinned away.

Fresh totals

Suite	Comparable rows	Ours	solc	Excess	Ratio
semanticTests	1,237	134,881,267	116,035,889	18,845,378	1.162x
gasTests	12	485,175	336,827	148,348	1.440x
Uniswap v4	44	1,950,079	907,063	1,043,016	2.150x
Aave v4	10	53,889,601	18,236,226	35,653,375	2.955x
Combined	1,303	191,206,122	135,516,005	55,690,117	1.411x

The current top 30 account for 48,519,047 gas, 87.1% of the total gap:

#	Suite	Fixture/scenario	Ours	solc	Excess	Ratio
1	Aave	PositionStatusMap:nextContinuousTenThousand()	21,191,126	5,975,804	15,215,322	3.55x
2	Aave	PositionStatusMap:nextCollateralContinuousTenThousand()	11,263,124	3,638,824	7,624,300	3.10x
3	Aave	PositionStatusMap:nextBorrowingContinuousTenThousand()	10,833,141	3,578,808	7,254,333	3.03x
4	semantic	various/negative_stack_height.sol	7,432,593	2,872,443	4,560,150	2.59x
5	Aave	PositionStatusMap:collateralCountMaxReserveScan()	4,952,818	2,297,830	2,654,988	2.16x
6	Aave	PositionStatusMap:borrowCountMaxReserveScan()	4,857,462	2,252,886	2,604,576	2.16x
7	semantic	array/copying/array_copy_including_array.sol	11,724,052	9,146,359	2,577,693	1.28x
8	semantic	storageLayoutSpecifier/dynamic_array_storage_end.sol	25,828,892	25,142,559	686,333	1.03x
9	semantic	array/copying/bytes_storage_to_storage.sol	1,388,700	835,859	552,841	1.66x
10	semantic	storageLayoutSpecifier/mapping_storage_end.sol	25,008,482	24,503,311	505,171	1.02x
11	semantic	array/array_storage_index_zeroed_test.sol	7,868,009	7,424,367	443,642	1.06x
12	Uniswap	TickMath:getTickAtSqrtPriceSweep()	626,662	203,628	423,034	3.08x
13	semantic	abicoder/abi_encode_call_memory_v2.sol	452,494	54,884	397,610	8.24x
14	semantic	storage/storage_boundary_struct_array_packed.sol	643,566	359,862	283,704	1.79x
15	semantic	storage/static_array_copy_cleanup.sol	546,020	266,625	279,395	2.05x
16	semantic	storage/storage_boundary_struct_array_mixed_types.sol	1,379,562	1,118,202	261,360	1.23x
17	semantic	array/array_storage_index_access.sol	7,045,162	6,816,025	229,137	1.03x
18	semantic	array/create_memory_array.sol	342,826	115,600	227,226	2.97x
19	semantic	operators/userDefined/all_possible_user_defined_value_types_with_operators.sol	216,885	1,581	215,304	137.18x
20	Aave	PositionStatusMap:flsFullRange()	382,678	193,873	188,805	1.97x
21	semantic	array/array_memory_index_access.sol	295,018	109,723	185,295	2.69x
22	semantic	array/slices/array_slice_calldata_as_argument_of_external_calls.sol	225,182	52,683	172,499	4.27x
23	Uniswap	TickMath:getSqrtPriceAtTickSweep()	239,461	73,316	166,145	3.27x
24	semantic	storage/storage_boundary_struct_array_multislot.sol	985,218	841,554	143,664	1.17x
25	semantic	storage/storage_boundary_delete_overflow_bug.sol	2,474,456	2,332,176	142,280	1.06x
26	semantic	events/event_indexed_string.sol	434,367	311,724	122,643	1.39x
27	semantic	array/invalid_encoding_for_storage_byte_array.sol	730,328	616,496	113,832	1.18x
28	semantic	array/pop/byte_array_pop_long_storage_empty.sol	255,219	152,429	102,790	1.67x
29	Uniswap	PoolSwap:swapExactInputNoTick()	138,059	44,284	93,775	3.12x
30	semantic	array/push/byte_array_push_transition.sol	237,705	146,505	91,200	1.62x

What solc optimized Yul is doing differently

The current passes remove many call sites, but preserve every function definition. Inlining also expands bodies into many small lets, assignments, conversion/cleanup blocks, and nested blocks without a general def-use cleanup and expression-rejoin phase.

Complete constructor + runtime object counts:

Representative source	Ours defs/calls	solc defs/calls	Ours stmts	solc stmts
Aave PositionStatusMap	150 / 131	19 / 107	3,952	1,007
bytes_storage_to_storage	76 / 45	6 / 17	1,008	208
user-defined-value-type operators	842 / 414	0 / 0	38,897	469
Uniswap TickMath	177 / 43	2 / 5	1,828	176
Uniswap PoolSwap	706 / 462	36 / 100	15,187	1,411
gasTests/dispatch_large	107 / 97	11 / 37	2,789	260

The main gap families are:

• Aave rows 1–3, 5–6, 20: these six rows are 99.69% of Aave's gap. Hot loops retain calls to next*, isBorrowing, isUsingAsCollateral, count, and bucket-word helpers, plus zero-return initialization, copy lets, cleanup blocks, repeated scratch mstore/Keccak/storage-address setup, and boolean normalization. solc keeps some real library functions, but their hot bodies are much closer to direct shifts/masks/sload/keccak256.
• Storage/array rows 4, 7–11, 14–17, 24–25, 27–28, 30: the missing ingredient is no longer just call inlining. We retain symbolic address reconstruction, repeated storage reads, scratch writes, checked loop scaffolding, generic short/long byte branches, width cleanup, and overwritten copy regions. StorageForward is intentionally too narrow to handle symbolic aliases or loop facts.
• TickMath rows 12 and 23: the two 100-iteration sweeps alone contribute 589,179 gas; all TickMath rows contribute 612,501. Both compilers retain the substantial math functions, but ours wraps operations in copy lets, zeroed results, conversions, and nested cleanup. Blindly inlining the large math functions is not the answer; expression joining, known-width simplification, and dead result cleanup are.
• ABI/memory/calldata rows 13, 18, 21, 22: generic allocator, bounds, cleanup, slicing, copy, and ABI layers remain after sizes, alignment, and non-aliasing are knowable. The 8.24x ABI-call row is a strong specialization target after common cleanup.
• User-defined types row 19: this is nearly an interprocedural constant program. solc eliminates every function; ours retains 842 definitions, 414 calls, and 38,897 statements. It is the clearest call-graph pruning + propagation + DCE target.
• PoolSwap row 29: all five PoolSwap cases are 217,508 gas over solc. The object has 706 definitions/462 calls versus 36/100, plus much more storage/memory scaffolding.

A newly exposed fixed backend cost

Full normalization hoists all functions to the root. The backend emits each definition as its own PUSH32 skip; JUMP; ...; JUMPDEST island, so ordinary execution pays about 12 gas per retained definition before dispatch. The optimizer currently removes none of those definitions.

Evidence:

• all 12 gasTests moved from 370,515 to 485,175 (+114,660, solc unchanged) when full normalization landed;
• dispatch_large retains 107 definitions and regressed by 27,091 gas per fixture, closely matching the repeated skip cost;
• Uniswap's 44 rows moved from 1,867,852 to 1,950,079 (+82,227, solc unchanged);
• Aave improved by 654,408 net because normalization enabled useful long-loop rewrites, but short calls still pay the fixed tax.

Recommended order

1. Fix the four behavior-stale fixtures and the 11 call-parser gaps first. This restores trustworthy longitudinal comparison.
2. Prune unreachable functions, then group the retained function section behind one skip. On normalized UniqueNames + FunctionsHoisted input, compute root reachability and the transitive SCC closure. This is the cheapest broad win, especially for row 19 and large Uniswap objects. Grouping is a complementary backend improvement for reachable definitions.
3. Add scoped def-use DCE and expression rejoining. Remove overwritten zero-result initialization, dead assignments/results, pure copy lets, empty blocks, and dead multi-return slots; rejoin single-use pure definitions subject to right-to-left evaluation and a stack-depth budget. This is the missing cleanup consumer after InlineCalls.
4. Generalize stack-aware inlining and specialization. Work SCC-by-SCC, never inline recursive edges, support guarded/multi-statement/multi-result helpers, and specialize on literal widths, masks, slots, and flags. Score after local propagation/DCE, including maximum live depth.
5. Add loop/state-aware dataflow. Symbolic must-alias storage forwarding, pure CSE, redundant equal-mstore removal, loop-invariant address/scratch setup, and induction/check recognition, with explicit invalidation at calls, stores, memory growth, and joins. This is the direct Aave and repeated-copy win.
6. Add known-bits/domain specialization. Prove cleanup/sign-extension idempotence, boolean and shift-range facts, concrete packed widths, short/long-byte decisions, and allocation/copy facts; then specialize ABI and storage-copy paths.

YulIR is promising as the representation for fused def-use/CSE/join work, but is not yet a production shortcut: YulIR.optimize is identity, and on its 608-program comparable corpus the round trip is 241,201 bytes versus 218,645 for the current optimizer (+10.3%, larger in 36/43 categories). It first needs proved ingestion/emission adequacy and pass soundness.

Expected Uniswap and Aave impact

Uniswap: recommendations 2–6 should improve all 14 compiling fixtures. The biggest targets are TickMath (612,501 excess), PoolSwap (217,508), PoolLiquidity (72,753), and SwapMath (52,480). PoolManager.sol, the sole rejection, is not mainly an optimizer problem: after guarded spilling it still reaches live gas, immutable, and linker-symbol boundaries. DCE can remove only unreachable occurrences. Supporting live occurrences requires source/target semantics, compiler/simulation proofs, and human review of the specification boundary.

Aave: recommendations 3–6 directly target the six rows responsible for 99.69% of its measured gap; function pruning/grouping mostly helps entry and short rows. HubOperations, LiquidationLogic, and SpokeOperations remain rejected at the same live gas/immutable/linker boundary; SpokeOperations also has an unguarded stack-pressure site. Better liveness/layout can solve the pressure site, but no optimizer profitability change can soundly accept unsupported live operations.

The detailed version, including the full rankings and pass notes, is now recorded in YulEvmCompiler/Optimizer/IDEAS.md.

[leonardoalt]

Update after PR #107 merged: #110 is rebased onto current main (d462e00) and
the baselines were regenerated through scripts/update-gas.sh, so these
numbers include scoped fact export and triple DeadResults rather than
rolling them back.

The stale-baseline causes are fixed rather than re-pinned over. The semantic
suite now has 1,264 comparable rows and its non-update check reports 0
regressions, 0 changed, 0 unpinned, and 0 stale. All 15 formerly stale fixtures
are covered again. The fix includes complete soltest value/directive parsing,
explicit treatment of OOG limit vectors, decoding escape-preserving Yul byte
literals at the execution boundary (restoring create_random CREATE2
agreement), and exact-baseline enforcement.

Current real-Solidity totals:

Suite	Rows	Ours	solc	Excess	Ratio
semanticTests	1,264	195,793,881	170,919,201	24,874,680	1.146x
gasTests	12	483,580	336,827	146,753	1.436x
Uniswap v4	44	1,778,850	907,063	871,787	1.961x
Aave v4	10	47,918,164	18,236,226	29,681,938	2.628x
Combined	1,330	245,974,475	190,399,317	55,575,158	1.292x

The current top 30 account for 48,005,289 excess gas (86.4% of the combined
gap):

#	Suite	Fixture/scenario	Ours	solc	Excess
1	Aave	PositionStatusMap.sol:nextContinuousTenThousand()	18,666,506	5,975,804	12,690,702
2	Aave	PositionStatusMap.sol:nextCollateralContinuousTenThousand()	9,997,154	3,638,824	6,358,330
3	Aave	PositionStatusMap.sol:nextBorrowingContinuousTenThousand()	9,567,171	3,578,808	5,988,363
4	semantic	various/negative_stack_height.sol	7,432,593	2,872,443	4,560,150
5	semantic	array/array_storage_push_pop.sol	16,719,419	14,028,568	2,690,851
6	semantic	array/copying/array_copy_including_array.sol	11,724,052	9,146,359	2,577,693
7	Aave	PositionStatusMap.sol:collateralCountMaxReserveScan()	4,526,251	2,297,830	2,228,421
8	Aave	PositionStatusMap.sol:borrowCountMaxReserveScan()	4,430,895	2,252,886	2,178,009
9	semantic	array/array_storage_index_access.sol	35,921,690	34,122,091	1,799,599
10	semantic	storageLayoutSpecifier/dynamic_array_storage_end.sol	31,781,574	30,681,201	1,100,373
11	semantic	array/array_storage_length_access.sol	2,342,594	1,306,640	1,035,954
12	semantic	array/copying/bytes_storage_to_storage.sol	1,388,505	835,859	552,646
13	semantic	storageLayoutSpecifier/mapping_storage_end.sol	24,995,482	24,503,311	492,171
14	semantic	array/array_storage_index_zeroed_test.sol	7,732,199	7,320,040	412,159
15	semantic	abicoder/abi_encode_call_memory_v2.sol	452,481	54,884	397,597
16	Uniswap	TickMath.sol:getTickAtSqrtPriceSweep()	523,513	203,628	319,885
17	semantic	array/array_storage_push_empty_length_address.sol	2,445,643	2,139,347	306,296
18	semantic	storage/storage_boundary_struct_array_packed.sol	641,928	359,862	282,066
19	semantic	storage/static_array_copy_cleanup.sol	537,281	266,625	270,656
20	semantic	storage/storage_boundary_struct_array_mixed_types.sol	1,377,924	1,118,202	259,722
21	semantic	array/create_memory_array.sol	342,626	115,600	227,026
22	semantic	array/array_memory_index_access.sol	294,836	109,723	185,113
23	semantic	array/slices/array_slice_calldata_as_argument_of_external_calls.sol	225,182	52,683	172,499
24	Aave	PositionStatusMap.sol:flsFullRange()	340,463	193,873	146,590
25	semantic	storage/storage_boundary_struct_array_multislot.sol	983,388	841,554	141,834
26	semantic	storage/storage_boundary_delete_overflow_bug.sol	2,472,620	2,332,176	140,444
27	Uniswap	TickMath.sol:getSqrtPriceAtTickSweep()	203,646	73,316	130,330
28	semantic	operators/userDefined/all_possible_user_defined_value_types_with_operators.sol	130,992	1,581	129,411
29	semantic	events/event_indexed_string.sol	428,755	311,724	117,031
30	semantic	array/invalid_encoding_for_storage_byte_array.sol	729,864	616,496	113,368

What remains different from solc optimized Yul:

• ours still retains every hoisted function definition and pays a per-function
  skip island; no call-graph reachability pass removes dead definitions;
• inlined helpers leave same-level copies, zero-result initialization, dead
  assignments, and nested readback blocks; optimizer: propagate facts across block exits (scoped export) #107 fixed cross-block fact loss
  but not general def-use cleanup or expression re-joining;
• Aave hot loops still pay retained helper calls, repeated storage-address /
  Keccak setup, cleanup masks, and checked-induction scaffolding;
• Uniswap TickMath still wraps multiply/shift/mask work in copy and cleanup
  scaffolding, while PoolSwap retains a much larger helper graph than solc;
• bytes, packed-storage, ABI, and array-copy paths lack symbolic alias facts,
  domain specialization, and loop-aware load/store forwarding.

Recommended order:

1. prune unreachable functions and group the remaining hoisted function
   section behind one skip;
2. finish same-level def-use cleanup and expression re-joining after optimizer: propagate facts across block exits (scoped export) #107;
3. add stack-aware SCC inlining and literal/width/slot specialization;
4. add state- and loop-aware dataflow, LICM, and induction simplification;
5. add known-bits, packed/bytes, and ABI/copy specialization.

These should improve both Uniswap and Aave. The largest current Uniswap
targets are TickMath (+469,563), PoolSwap (+217,508), SwapMath (+52,480), and
PoolLiquidity (+49,891). The six Aave traversal/scan rows still account for
99.69% of its excess, so recommendations 2-5 directly target it; function
pruning mainly helps entry and shorter paths.

PR #109 also changes the YulIR assessment: it is no longer an identity
optimizer. Simplification, immutable value numbering/CSE, structural cleanup,
dead-store, and dead-code passes now put it within 0.009% of production
execution gas and 1.2% of production code size on yulOptimizerTests.
It does not improve Uniswap/Aave yet because ingestion/emission and pass
soundness are interpreter-checked rather than proved and the pipeline is not
wired into production. It should be benchmarked on those contracts, then
proved/composed or used to prototype inlining, load resolution,
rematerialization, stack-aware scheduling, and LICM.

The full temporary analysis is kept in this issue comment. The IDEAS.md diff on #110 only updates permanent normalization and #107 pass-log entries.

[leonardoalt]

Update: recommendation 3 (first slice) landed — PR #107 (2026-07-25)

Scoped fact export across block exits (Propagate) plus a deadResults pacing fix are merged. Propagate used to discard every tracked fact at nested-block exit, so the inliner readback scaffolding (let x { … x := 0 } y := x) that dominates the six PositionStatusMap hot rows never folded, and helper bodies stayed above the shared liveMax ≤ 12 copy/inline gates. The .block case now exports the body's final environment minus the block's direct locals, and deadResults runs three times per round because the export kills whole groups of adjacent readback regions at once while that stage drains one region per statement sequence per invocation.

Measured against the totals in the refresh above (solc 0.8.35, corpus 902f848, zero regressions on all 1,303 comparable rows):

Suite	Before	After	Δ	Ratio
Aave v4	53,889,601	47,918,164	−5,971,437	2.955x → 2.628x
semanticTests	134,881,267	134,383,334	−497,933	1.162x → 1.158x
Uniswap v4	1,950,079	1,778,850	−171,229	2.150x → 1.961x
gasTests	485,175	483,580	−1,595	1.440x → 1.436x

Row-level: nextContinuousTenThousand −2,524,464, nextBorrowingContinuousTenThousand −1,265,970, nextCollateralContinuousTenThousand −1,265,970, both count scans −426,567 each, flsFullRange −42,215. PositionStatusMap runtime bytecode 93,144 → 86,508 bytes (−7.1%). Combined ours-vs-solc gap −11.9%.

The 15 stale and 118 unpinned semantic baseline rows flagged above were deliberately not re-pinned away — membership is unchanged in every baseline and those rows still await the baseline-integrity work (item 1 of the recommended order).

Remaining hot-loop cost after this change (fresh dumps): same-level copy chains still gated off by copyGate in fat bodies, the retained hot helpers (getBucketWord/isBorrowing/isUsingAsCollateral) still pay the call protocol every inner iteration, read let x { x := e } declare-then-assign pairs, and the per-iteration scratch mstore/Keccak/sload setup. Recommendations 4 (stack-aware inlining/specialization) and 5 (loop/state-aware dataflow) now start from much smaller bodies; details in YulEvmCompiler/Optimizer/IDEAS.md.