Commit Graph
6 Commits
Author SHA1 Message Date
98d818f958 The new Yul optimizer toolkit (#519)
This PR introduces powerful code size optimizations. This is achieved
with an additional IR layer in between Yul and LLVM IR. It works quite
well (see below for a comparison) because it captures optimization gains
that neither solc nor LLVM can realize.

The feature is gated behind `--newyork` or a corresponding standard JSON
input setting and **off by default**.

### How it works

We implemented an SSA IR modelled after or inspired by the [MLIR SCF
dialect](https://mlir.llvm.org/docs/Dialects/SCFDialect/). Yul is
translated into this IR and the IR implements mainly the following
optimizations:

- **Type narrowing**: narrows 256-bit values to I1..I160 where provable
(bidirectional + interprocedural), so LLVM emits native 32/64-bit ops
instead
    of software 256-bit arithmetic.
- **FMP range proof**: exposes the `mload(0x40) < heap_size` bound to
LLVM
IPSCCP, eliminating trailing overflow checks on FMP-derived offsets.
Single
    largest code-size contributor.
- **Heap analysis**: skips big-endian byte-swaps where native
little-endian
    layout is safe.
  - **mem_opt / keccak fusion+folding**, **compound outlining** (mapping
sload/sstore), **guard narrowing**, **inlining** tuned for PolkaVM, and
    **exact + fuzzy function dedup**.

### Results
The optimizations implemented with the newyork IR bring substantial code
size improvements.
  - Integration contracts: approximately **-20% to -50%** code size.
  - OpenZeppelin Wizard corpus: around **-47%** code size.

This table shows the code size improvements on various OpenZeppelin ERC
implementations, taken from their [contracts
wizard](https://wizard.openzeppelin.com/), with almost all features
enabled.

| Contract | Default: (bytes) | With `--newyork`: (bytes) | Reduction |
|---|---:|---:|---:|
| erc1155 | 59,206 | 30,649 | -48.2% |
| erc20 | 81,697 | 42,893 | -47.5% |
| erc721 | 92,052 | 49,423 | -46.3% |
| oz_gov | 141,861 | 81,159 | -42.8% |
| oz_rwa | 77,274 | 37,975 | -50.9% |
| oz_simple_erc20 | 29,950 | 16,554 | -44.7% |
| oz_stable | 82,117 | 39,032 | -52.5% |
| **Total** | **564,157** | **297,685** | **-47.2%** |

We believe this to be a reasonably representative dataset and conclude
that the newyork IR achieves drastic code size reductions on real world
dApp implementations.

### Methodology, security and runtime performance

Since the main contributors to these improvements are the FMP range
proofs and the type narrowing, we don't expect big runtime performance
regressions (it may even benefit runtime performance in some cases).

The PR also includes docs
(`book/src/developer_guide/newyork_{optimizer,ir}.md`) and many new
integration tests, including regression tests for known FMP soundness
traps.

The PR was authored collaboratively and reviewed extensively by the
`revive` maintainers, as well as Claude Opus, Claude Fable, Qwen,
Minimax and Deepseek LLMs, over a span of many months.

The `newyork` compiler pipeline introduces no new regressions over our
integration and differential test suites (containing over 30000 test
cases). This was achieved by careful manual reviews and many LLM bughunt
loops. Additionally, a final security review by Anthropic's Fable 5 LLM
found no remaining soundness issues. Nonetheless, like any brand new
software, please consider this an experimental feature upon release.

---------

Signed-off-by: xermicus <bigcyrill@hotmail.com>
Signed-off-by: xermicus <cyrill@parity.io>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: neo <me@90f9.org>
Co-authored-by: LJ <81748770+elle-j@users.noreply.github.com>
2026-06-17 12:35:16 +02:00
LJandxermicus 0742227c5a Implement Yul to LLVM IR compilation benchmarks (#407)
# Description

Closes [#404](https://github.com/paritytech/revive/issues/404)

Adds compilation time benchmarks for:

* Parsing of Yul source code -> AST Object
* Lowering of AST Object -> LLVM IR (unoptimized)

The benchmarks can be run from the root via:

```sh
# Run all benchmarks in the revive-yul crate (parsing + lowering)
make bench-yul
```

HTML reports will be generated under `target/criterion`, and a summary
of the results at
[crates/yul/BENCHMARKS_PARSE_M4PRO.md](https://github.com/paritytech/revive/blob/lj/compilation-benchmarks-yul/crates/yul/BENCHMARKS_PARSE_M4PRO.md)
and
[crates/yul/BENCHMARKS_LOWER_M4PRO.md](https://github.com/paritytech/revive/blob/lj/compilation-benchmarks-yul/crates/yul/BENCHMARKS_LOWER_M4PRO.md)
(currently from running on a Mac M4 Pro).

---------

Co-authored-by: xermicus <cyrill@parity.io>
2025-11-25 12:00:06 +01:00
xermicus 94ec34c4d5 Separate compilation and linker phases (#376)
Separate between compilation and linker phases to allow deploy time
linking and back-porting era compiler changes to fix #91. Unlinked
contract binaries (caused by missing libraries or missing factory
dependencies in turn) are emitted as raw ELF object.

Few drive by fixes:
- #98
- A compiler panic on missing libraries definitions.
- Fixes some incosistent type forwarding in JSON output (empty string
vs. null object).
- Remove the unused fallback for size optimization setting.
- Remove the broken `--lvm-ir`  mode.
- CI workflow fixes.

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Signed-off-by: xermicus <bigcyrill@hotmail.com>
Signed-off-by: xermicus <cyrill@parity.io>
2025-09-27 20:52:22 +02:00
xermicus b238913a7d emit YUL builtins debug line info and fix debug info source file (#358)
This PR fixes and enhances debug info generation:
1. Adds line information for each lowered YUL builtin and the `if`
statement.
2. Fixes the debug info source path to match the YUL file of the
contract dumped to the `--debug-output-dir`.

This improves inspection of the generated code a lot. Excerpt from
`llvm-objdump -Sl /tmp/dbg/contracts_EndpointV2.sol.EndpointV2.so`:

```
; /tmp/dbg/contracts_EndpointV2.sol.EndpointV2.yul:203
;                 let _1 := memoryguard(0x80)
   13c3e: 3aa5b023      sd      a0, 0x3a0(a1)
   13c42: 38a5bc23      sd      a0, 0x398(a1)
   13c46: 38a5b823      sd      a0, 0x390(a1)
   13c4a: 08000513      li      a0, 0x80
   13c4e: 38a5b423      sd      a0, 0x388(a1)
; /tmp/dbg/contracts_EndpointV2.sol.EndpointV2.yul:204
;                 mstore(64, _1)
   13c52: 3885b503      ld      a0, 0x388(a1)
   13c56: 3905b603      ld      a2, 0x390(a1)
   13c5a: 3985b683      ld      a3, 0x398(a1)
   13c5e: 3a05b703      ld      a4, 0x3a0(a1)
   13c62: 38e5b023      sd      a4, 0x380(a1)
   13c66: 36d5bc23      sd      a3, 0x378(a1)
   13c6a: 36c5b823      sd      a2, 0x370(a1)
   13c6e: 36a5b423      sd      a0, 0x368(a1)
   13c72: 04000513      li      a0, 0x40
   13c76: 65d9          lui     a1, 0x16
   13c78: a605859b      addiw   a1, a1, -0x5a0
   13c7c: 95a6          add     a1, a1, s1
   13c7e: 00000097      auipc   ra, 0x0
   13c82: 000080e7      jalr    ra <__runtime+0x1de>

0000000000013c86 <.Lpcrel_hi27>:
; /tmp/dbg/contracts_EndpointV2.sol.EndpointV2.yul:205
;                 if iszero(lt(calldatasize(), 4))
   13c86: 00000517      auipc   a0, 0x0
   13c8a: 00053503      ld      a0, 0x0(a0)
   13c8e: 4108          lw      a0, 0x0(a0)
   13c90: 4591          li      a1, 0x4
   13c92: 06b56263      bltu    a0, a1, 0x13cf6 <.Lpcrel_hi27+0x70>
   13c96: a009          j       0x13c98 <.Lpcrel_hi27+0x12>
```

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
2025-07-04 19:56:52 +02:00
xermicus 486c9c28a1 new clippies (#352)
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
2025-06-28 11:48:24 +02:00
xermicus bd4e108bb0 resolc crate (#328)
- Factor the YUL crate out of `revive-solidity`.
- `revive-solidity` is in reality not a Solidity implementation but the
revive solidity compiler driver (`resolc`). By renaming we not only get
this straight but also a binary with the same name as the crate which
should be less confusing.

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
2025-05-27 09:48:43 +02:00