resolc v1.4.0
Supported `polkadot-sdk` rev: `2604.2.0`
### Added
- Support for solc v0.8.36 and the "Amsterdam" EVM version.
### Fixed
- Restored the top-level `revive_version` field in `--standard-json`
output and the `resolc_version` field in `--combined-json` output, both
of which stopped being populated in `v0.4.0`.
[#557](https://github.com/paritytech/revive/pull/557)
- ICE triggered by `--disable-solc-optimizer --newyork` where inlined
loops could emit an unterminated basic block in the inlined entrypoint.
[#561](https://github.com/paritytech/revive/pull/561)
- `--newyork`: dead-store elimination could drop a store whose memory
expansion an intervening `msize()` observes, so `msize()` read a stale
(unexpanded) value.
[#565](https://github.com/paritytech/revive/pull/565)
- `--newyork`: dead-store elimination could drop a store that a later
overlapping unaligned `mload` reads, returning zeroed memory instead of
the stored bytes. [#563](https://github.com/paritytech/revive/pull/563)
- `--newyork`: an unaligned full-word `mload`/`mstore` overlapping a
word kept native (little-endian) by the heap optimization returned
byte-swapped bytes.
[#562](https://github.com/paritytech/revive/pull/562)
- `--newyork`: a `calldatacopy`/`codecopy`/`returndatacopy` to a dynamic
destination that could overwrite the free-memory-pointer word truncated
a subsequent `mload(0x40)` to `0`.
[#564](https://github.com/paritytech/revive/pull/564)
- `--newyork`: a full-width value stored to the free-memory-pointer slot
(e.g. a function parameter `>= 2^64`) was narrowed to 64 bits, inserting
a checked truncation that consumed all gas.
[#567](https://github.com/paritytech/revive/pull/567)
- `--newyork`: an unaligned `mstore` corrupting the free-memory-pointer
word let a later store through the corrupted pointer silently succeed
where EVM runs out of gas.
[#566](https://github.com/paritytech/revive/pull/566)
- Fixed a bytecode divergence (yet functionally equivalent) between the
resolc Linux/macOS builds and the Windows build for contracts with loops
indexing array elements at constant offsets from a `uint8` loop variable
(e.g. `array[i]`/`array[i + 1]`), compiled with `--newyork` at `-Oz`
with the solc optimizer disabled.
[#570](https://github.com/paritytech/revive/pull/570)
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
## Description
Our differential bytecode comparison tests detected a bytecode mismatch
between the Linux/macOS builds and the Windows build for a
[contract](https://github.com/paritytech/resolc-compiler-tests/blob/4647018d64eab6ccff30d22c753f02b90e9fc7e3/fixtures/solidity/simple/internal_function_pointers/sort/bubble.sol)
implementing recursive bubble sort, specifically with these opt
settings:
* Solc optimizer disabled
* Newyork enabled
* `-Oz`
This PR applies an [LLVM
patch](https://github.com/llvm/llvm-project/pull/190587) which fixes the
divergence for contracts with loops that index array elements at
constant offsets from a Solidity `uint8` loop variable, observed with
the above opt settings.
## Cause
The first divergence occurs in an LLVM Loop Strength Reduction (LSR)
decision, on `bubbleSort`'s loop (`for (uint8 i = 0; i < ARRAY_SIZE -
start - 1; i++)` with `array[i]`/`array[i+1]` accesses):
```diff
- %lsr.iv = phi i32 [ 0, %for_cond.preheader153 ], [ %lsr.iv.next, %if_join64 ] ; Linux/macOS
+ %lsr.iv = phi i32 [ 1, %for_cond.preheader153 ], [ %lsr.iv.next, %if_join64 ] ; Windows
+ %3 = add i32 %lsr.iv, -1 ; Windows
...
- %3 = add i32 %lsr.iv, 1 ; Linux/macOS
...
%lsr.iv.next = add nuw nsw i32 %lsr.iv, 1 ; identical on both platforms: step is +1 either way
```
In LLVM's `{Start,+,Step}` recurrence notation (value starts at `Start`,
changes by `Step` per loop iteration), the three constants in the diff
represent: recurrence *start*, use-site *offset*, and recurrence *step*.
Only the first two differ between the platforms:
**Linux/macOS** (the `array[i]` calls take `%lsr.iv` directly; the
`array[i+1]` calls take `%3`):
| Line | Constant | Role |
|---|---|---|
| `%lsr.iv = phi i32 [ 0, … ]` | `0` | **Start**: the register's value
on loop entry (`i`) (holds 0, 1, 2, …) |
| `%3 = add i32 %lsr.iv, 1` | `+1` | **Use-site offset**: derives the
*other* index (`i + 1`) from the register each iteration. (No register
is dedicated to `%3`) |
| `%lsr.iv.next = add … , 1` | `+1` | **Step**: how much the register
advances each iteration |
**Windows** (mirrored: the `array[i+1]` calls take `%lsr.iv` directly;
the `array[i]` calls take `%3`):
| Line | Constant | Role |
|---|---|---|
| `%lsr.iv = phi i32 [ 1, … ]` | `1` | **Start**: the register's value
on loop entry (`i + 1`) (holds 1, 2, 3, …) |
| `%3 = add i32 %lsr.iv, -1` | `-1` | **Use-site offset**: derives the
*other* index (`i`) from the register each iteration. (No register is
dedicated to `%3`) |
| `%lsr.iv.next = add … , 1` | `+1` | **Step**: identical |
The two solutions are mirror images with exactly equal cost, because
`getSetupCost()` (the patched function) rated *any* constant induction
variable (IV) start equally (a 0-start and a 1-start IV cost the same).
LSR keeps the first solution it enumerates, and the enumeration order
derives from walking SSA use-lists, whose in-memory order differed
between our Linux/macOS and Windows builds of LLVM.
Thus both platforms compute the indices `i` and `i + 1` each iteration
(functionally identical), but the LSR decision of which of the two
recurrences becomes the loop-carried value (the phi) differs, which
affects register allocation.
> [!NOTE]
> The equal cost tie can only arise if LSR processes the loop at all,
and LSR only forms uses for induction variables of a 32-bit or 64-bit
integer in our case.
## Partial solution
The [upstream fix](https://github.com/llvm/llvm-project/pull/190587)
updates `getSetupCost()` to return `0` for constant IV starts whose
materialization is `TCC_Free` (which immediate `0` on RISC-V is), which
is now cheaper than non-zero starts, resulting in the same LSR decision
(no tie to decide on) on Windows as well.
As zero-start IVs are most common, this fix addresses the most common
scenarios, but it is still only a partial fix as it specifically solves
only the zero-start case. (I'm currently writing up another issue
regarding this.)
## Verification
I created a draft LLVM release that was built with the patch applied,
then reran all workflows using the draft release, including temporarily
testing more opt settings for the bytecode comparisons which ran
successfully (no mismatches) with the following `retester` modes (see
[this
run](https://github.com/paritytech/revive/actions/runs/28970814016/job/85982029937)):
* `NY M0 S+`
* `NY M0 S-`
* `NY M3 S+`
* `NY M3 S-`
* `NY Mz S+`
* `NY Mz S-`
* `Y M0 S+`
* `Y M0 S-`
* `Y M3 S+`
* `Y M3 S-`
* `Y Mz S+`
* `Y Mz S-`
All E2E tests also ran as it does today (allowing all Yul and newyork IR
`retester` modes), completing successfully.
Bug found by @jubnzv:
`--newyork`: an unaligned `mstore` corrupting the free-memory-pointer
word let a later store through the corrupted pointer silently succeed
where EVM runs out of gas.
---------
Signed-off-by: xermicus <bigcyrill@hotmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug found by @jubnzv:
`--newyork`: a full-width value stored to the free-memory-pointer slot
(e.g. a function parameter `>= 2^64`) was narrowed to 64 bits, inserting
a checked truncation that consumed all gas.
---------
Signed-off-by: xermicus <bigcyrill@hotmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug found by @jubnzv:
`--newyork`: dead-store elimination could drop a store whose memory
expansion an intervening `msize()` observes, so `msize()` read a stale
(unexpanded) value.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug found by @jubnzv:
`--newyork`: a `calldatacopy`/`codecopy`/`returndatacopy` to a dynamic
destination that could overwrite the free-memory-pointer word truncated
a subsequent `mload(0x40)` to `0`.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Agent <agent@local>
Another bug found by @jubnzv:
`--newyork`: dead-store elimination could drop a store that a later
overlapping unaligned `mload` reads, returning zeroed memory instead of
the stored bytes.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Another bug found by @jubnzv:
`--newyork`: an unaligned full-word `mload`/`mstore` overlapping a word
kept native (little-endian) by the heap optimization returned
byte-swapped bytes.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Description
The resolc long version stopped being populated on the standard JSON and
combined JSON output. This PR restores these fields and populates them.
## v1.3.0
Supported `polkadot-sdk` rev: `2604.2.0`
### Added
- The newyork IR code size optimization pipeline, selectable via the
`--newyork` CLI flag or the `settings.polkavm.newyork` standard JSON
input field.
This can reduce code size by up to 50%. Considered a new and
experimental feature, switched off by default.
[#519](https://github.com/paritytech/revive/pull/519)
### Changed
- The latest supported `polkadot-sdk` version is now `2604.2.0`
Signed-off-by: xermicus <cyrill@parity.io>
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>
Supported `polkadot-sdk` rev: `2603`
### Changed
- Updated `LLVM` from `21.1.8` to LLVM `22.1.4`
### Added
- Support for solc v0.8.35.
### Fixed
- A constant folding bug causing incorrect translation of a signed
remainder edge case. The affected pattern (Solidity % or Yul smod):
- SREM over the two constant operands `type(int256).min` and `-1`.
- At least one of the two constants needs folding (i.e. not just
`type(int256).min % -1`),
and is written specifically such that solc doesn't fold but LLVM does,
resulting in UB (signed-overflow).
- Fix `mulmod` returning out-of-range result for large moduli.
---------
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Existing test coverage didn't catch a signed remainder overflow
semantics edge case behavior where at least one the operators is being
constant folded by LLVM instead of solc. This PR fixes the SREM
translation bug and adds missing test coverage for division ops with
constants.
Closes#524
---------
Signed-off-by: xermicus <cyrill@parity.io>
- Support solc v0.8.35
- The new `erc7201` is comptime (already translated to a constant in
Yul)
Didn't spot any relevant breakage or addition in the release notes so
should be no-brainer.
---------
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
## Description
Applies LLVM patches that have not been backported to the major version
used in our submodule:
* [LLVM PR #163679](https://github.com/llvm/llvm-project/pull/163679)
* *"[RISCV] Allow large div peephole optimization for minsize"*
* Fixes peephole optimization of large integers when `minsize` function
attribute is set.
* (Our revive codebase used a workaround that can be removed once this
500 PR is merged and we publish a new LLVM release.)
* [LLVM PR #190219](https://github.com/llvm/llvm-project/pull/190219)
* *"[TargetLowering] Speculative fix for a non-determinism issue between
different compilers"*
* Operand ordering of `mul i256` were different depending on the target
ABI when building LLVM, producing different RISC-V and PVM bytecode for
our Windows vs macOS/linux builds.
* The bytecode divergence (yet functionally equivalent) affected
Solidity contracts containing a value [multiplied by
itself](https://github.com/llvm/llvm-project/issues/190148) (e.g. via
explicit squaring or exponentiation), manifesting primarily when using
optimization level `-O0`.
## Description
Switches the Windows LLVM build from Visual Studio to `clang-cl` +
`lld-link` (Clang's MSVC-compatible drivers) with Ninja.
This is in order to better match the Clang toolchain used on our Linux
and macOS variants, while keeping the MSVC ABI.
It also speeds up the build time by at least 2x on Windows.
Emscripten 4.0.12 introduced breaking change by changing module factory
to always return promise even if `WASM_ASYNC_COMPILATION=0`. To overcome this, build emscripten compiler without MODULARIZE with custom export of `createRevive`.
As a drive-by fix, the get-llvm action now ignores LLVM releases marked
as pre-release.
---------
Signed-off-by: xermicus <bigcyrill@hotmail.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
In `--yul` mode, resolc now properly exits when solc reports validation
errors (e.g., invalid hex literals, variable redeclarations), matching
`--standard-json behavior.`
`runs_without_input_file` was adapted because it was relying on it where
the new behavior correctly matches solc --strict-assembly.
Closes#477
Co-authored-by: minimax-m2.5 <neo@zion>
---------
Signed-off-by: xermicus <bigcyrill@hotmail.com>
The `--bin` CLI flag was not producing bytecode because the
`outputSelection` was not updated to explicitly requested it.
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
This marks a milestone: Smart contracts on Polkadot Asset Hub are live
and we release the first compiler version!
Signed-off-by: xermicus <bigcyrill@hotmail.com>
# Description
Compilation times for resolc were significantly slower than solc when:
* Multiple files were included in the JSON input file via
`--standard-json`
* And none of the files requested code generation
* (If only a subset of files requested code generation, both resolc and
solc were very slow)
Reason:
* Resolc unconditionally generated bytecode for all contracts, even if
not requested.
* When compiling to PolkaVM bytecode, we need to pass additional flags
(e.g. `irOptimized`) to solc. If these flags were not explicitly
requested, resolc also added these to the requested output since PolkaVM
bytecode was always generated.
## Breaking Changes
The following changes are breaking, but fix the semantics to match its
intended behavior:
* Compiling with `--standard-json` now compiles to PolkaVM bytecode
***only*** for the contracts explicitly requested in the
`outputSelection`.
* Compiling with `--standard-json` now outputs ***only*** the explicitly
requested output (e.g. `evm.assembly`, `evm.bytecode`, `ast`, etc.).
```jsonc
// Example:
{
"settings": {
// ...
"outputSelection": {
"src/common/GasService.sol": {
// Contracts in this file will generate bytecode.
// Only these fields of the JSON output selection will be in the `contracts` output.
"*": ["abi", "evm.methodIdentifiers", "metadata", "evm.bytecode"],
// Only this field of the JSON output selection will be in the `sources` output.
"": ["ast"]
},
"src/common/Gateway.sol": {
// No contracts in this file will generate bytecode.
"*": ["abi", "evm.methodIdentifiers", "metadata"],
// No `ast` will be in the `sources` output (only the automatically added `id`,
// similar to solc as this is not a configurable output selection).
"": []
},
}
}
}
```
## Performance Improvements
When e.g. the standard JSON input file includes multiple files and
requests output for every contract as per this setting:
```jsonc
{
"settings": {
// ...
"optimizer": { "enabled": true, "runs": 1 },
"viaIR": true,
"outputSelection": {
"src/common/GasService.sol": {
"*": ["abi", "evm.methodIdentifiers", "metadata", "evm.bytecode"],
},
// Rest of files..
}
}
}
```
The differences in compilation times depending on whether `evm.bytecode`
is selected in every file, one file, or no files can be seen below:
| Solc Optimizer (runs=1) | ViaIR | Request `abi`,
`evm.methodIdentifiers`, `metadata` | Request `evm.bytecode` | resolc
before | resolc after | solc v0.8.33 |
|:-----------------------:|:-----:|:---------:|:---------:|:-------------:|:------------:|:----------:|
| ✅ | ✅ | All files | All files | `~14.5s` | `~14.5s` | `~13.5s` |
| ✅ | ✅ | All files | One file | `~14.5s` | `~450ms` | `~13.5s` |
| ✅ | ✅ | All files | No files | `~14.5s` | `~390ms` | `~350ms` |
**Observations:**
* `resolc before` is roughly the same no matter the request
* This is due to unconditionally generating bytecode
* When not requesting bytecode for any contracts:
* `resolc after` now compiles in ~390ms (vs ~14.5s), similar to `solc`
* Neither `solc` nor `resolc after` generates bytecode when none of the
contracts request it
* When requesting bytecode for all contracts in _only one_ file:
* `resolc after` now compiles in ~450ms (vs ~14.5s)
* `solc` still compiles in the same time as when requesting bytecode for
all contracts in all files
* This is something they have tried to improve (see
[Solidity#15373](https://github.com/argotorg/solidity/issues/15373) and
[Solidity#15615](https://github.com/argotorg/solidity/issues/15615)),
and the intended behavior seems to now be that bytecode should only be
generated when explicitly requested for each contract.
* Even though PRs have merged to try to fix it, their issue seems to
persist as of v0.8.33.
# Open Questions
* Foundry:
* [x] Pruning of the AST:
* Just saw [this past
commit](https://github.com/paritytech/revive/pull/385) to not prune the
AST for Foundry compatibility.
* Can Foundry not explicitly request `"": "ast"`?
* **Answer:**
* Pruning the AST when not requested should be fine, as long as Foundry
explicitly requests it when needed.
* Will be tested by Foundry maintainer.
# Review Notes
Changes in `docs/` (~25 files) can be skipped as they are automatically
updated after adding content to `book/` and rebuilding it.
# Resolved Issues
Closes#326
---------
Co-authored-by: xermicus <cyrill@parity.io>
- Remove the superfluous byte swap in the `linkersymbol` builtin
translation.
- Support testing the `linkersymbol` builtin translation in the runner
specs.
---------
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
The OOB logic is implemented in the runtime but truncation circumvented
it.
Closes#263
---------
Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Fixes https://github.com/paritytech/contract-issues/issues/149
A few test cases from v2-periphery-polkadot are hitting the PVM stack
limit when the contracts are compiled using resolc version 0.5.0. The
same tests pass if the contracts are compiled with a resolc version that
includes commit:
https://github.com/paritytech/revive/commit/878ca91689b99220f7ffd40df760613b7314de86.
After a brief discussion with @xermicus, we propose to set the default
PolkaVM stack and heap size values to 128KB, since we have already
encountered tests that hit the stack size limit and, without real world
data, it is difficult to determine the optimal values.
This PR fixes a small oversight from #431: Set the debug config of the
revive-runner `Runtime` such that we get the PVM logs back. Since the
revive runner runtime is mainly meant for debugging, I further decided
to enable unlimited contract sizes and disable [EIP
3607](https://eips.ethereum.org/EIPS/eip-3607) too.
---------
Signed-off-by: xermicus <cyrill@parity.io>
- Emit the `call_evm` and `delegate_call_evm` syscalls for contract
calls.
- The call gas is no longer ignored.
---------
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Support for `polkadot-sdk` release `unstable2507`. This release will be
deployed to Kusama and is supposed the first one on Polkadot.
---------
Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
These compiler outputs are irrelevant for the `resolc` compilation
pipeline. It can also break the compilation pipeline. For example, solc
may reject the code without via-ir or fail during the EVM codegen phase
with stack too deep errors - which is not relevant to us.
---------
Signed-off-by: xermicus <cyrill@parity.io>
Note:
- The unstable interface in `v2509.0.0` of `polkadot-sdk` is required.
- The differential test fails against EVM in `v2509.0.0` of
`polkadot-sdk`.
---------
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
xermicus