mirror of
https://github.com/pezkuwichain/revive.git
synced 2026-10-20 18:56:17 +00:00
98d818f958
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>
32 lines
5.4 KiB
HTML
32 lines
5.4 KiB
HTML
<!DOCTYPE HTML>
|
|
<html lang="en" class="light" dir="ltr">
|
|
<head>
|
|
<!-- sidebar iframe generated using mdBook
|
|
|
|
This is a frame, and not included directly in the page, to control the total size of the
|
|
book. The TOC contains an entry for each page, so if each page includes a copy of the TOC,
|
|
the total size of the page becomes O(n**2).
|
|
|
|
The frame is only used as a fallback when JS is turned off. When it's on, the sidebar is
|
|
instead added to the main page by `toc.js` instead. The JavaScript mode is better
|
|
because, when running in a `file:///` URL, the iframed page would not be Same-Origin as
|
|
the rest of the page, so the sidebar and the main page theme would fall out of sync.
|
|
-->
|
|
<meta charset="UTF-8">
|
|
<meta name="robots" content="noindex">
|
|
<!-- Custom HTML head -->
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<meta name="theme-color" content="#ffffff">
|
|
<link rel="stylesheet" href="css/variables-8adf115d.css">
|
|
<link rel="stylesheet" href="css/general-2459343d.css">
|
|
<link rel="stylesheet" href="css/chrome-ae938929.css">
|
|
<link rel="stylesheet" href="css/print-9e4910d8.css" media="print">
|
|
<!-- Fonts -->
|
|
<link rel="stylesheet" href="fonts/fonts-9644e21d.css">
|
|
<!-- Custom theme stylesheets -->
|
|
</head>
|
|
<body class="sidebar-iframe-inner">
|
|
<ol class="chapter"><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="welcome.html" target="_parent"><strong aria-hidden="true">1.</strong> Welcome</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide.html" target="_parent"><strong aria-hidden="true">2.</strong> resolc user guide</a></span><ol class="section"><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide/installation.html" target="_parent"><strong aria-hidden="true">2.1.</strong> Installation</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide/cli.html" target="_parent"><strong aria-hidden="true">2.2.</strong> Command Line Interface</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide/js.html" target="_parent"><strong aria-hidden="true">2.3.</strong> JS NPM package</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide/tooling.html" target="_parent"><strong aria-hidden="true">2.4.</strong> Tooling integration</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide/std_json.html" target="_parent"><strong aria-hidden="true">2.5.</strong> Standard JSON interface</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide/differences.html" target="_parent"><strong aria-hidden="true">2.6.</strong> Differences to EVM</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="user_guide/rust_libraries.html" target="_parent"><strong aria-hidden="true">2.7.</strong> Rust contract libraries</a></span></li></ol><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="revive_runner.html" target="_parent"><strong aria-hidden="true">3.</strong> revive-runner sandbox</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide.html" target="_parent"><strong aria-hidden="true">4.</strong> Developer Guide</a></span><ol class="section"><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide/contributing.html" target="_parent"><strong aria-hidden="true">4.1.</strong> Contributor guide</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide/architecture.html" target="_parent"><strong aria-hidden="true">4.2.</strong> Compiler architecture</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide/newyork_optimizer.html" target="_parent"><strong aria-hidden="true">4.3.</strong> The newyork optimizer</a></span><ol class="section"><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide/newyork_ir.html" target="_parent"><strong aria-hidden="true">4.3.1.</strong> IR reference</a></span></li></ol><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide/target.html" target="_parent"><strong aria-hidden="true">4.4.</strong> PVM and the pallet-revive runtime target</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide/testing.html" target="_parent"><strong aria-hidden="true">4.5.</strong> Testing strategy</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="developer_guide/cross_compilation.html" target="_parent"><strong aria-hidden="true">4.6.</strong> Cross compilation</a></span></li></ol><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="faq.html" target="_parent"><strong aria-hidden="true">5.</strong> FAQ</a></span></li><li class="chapter-item expanded "><span class="chapter-link-wrapper"><a href="roadmap.html" target="_parent"><strong aria-hidden="true">6.</strong> Roadmap and Vision</a></span></li></ol>
|
|
</body>
|
|
</html>
|