Deduplicate bytecode dependencies used by both creation and deployed object #15178
Labels
low effort
There is not much implementation work to be done. The task is very easy or tiny.
low impact
Changes are not very noticeable or potential benefits are limited.
performance 🐎
should have
We like the idea but it’s not important enough to be a part of the roadmap.
Abstract
When a contract deploys another contract (via
new
) or accesses its bytecode (via.runtimeObject
or.creationCode
), the compiler embeds that bytecode in the accessing contract. Depending on whether the contract is accessed at creation time or at runtime, its bytecode ends up as a subassembly of the creation or runtime assembly, respectively. However, when it is accessed at both times it ends up being included in both places.This happens in both the legacy and the IR pipeline.
Details
This behavior can be clearly seen in the IR codegen. It's clear that there's no attempt at deduplication:
solidity/libsolidity/codegen/ir/IRGenerator.cpp
Line 184 in 8a97fa7
solidity/libsolidity/codegen/ir/IRGenerator.cpp
Line 206 in 8a97fa7
Motivation
This duplication not only increases bytecode size but also requires the compiler to optimize the same code twice, which is especially problematic for the IR pipeline.
How to reproduce
solc test.sol --bin --optimize | fold --width 115
Bytecode of
C
clearly is included inside bytecode ofD
twice. The long string included in the source can be seen twice as two long sequences of0x44
.The effect is similar with
--via-ir
, though the string is not as easily visible. Still, it can be easily confirmed by removingD
's constructor - it cuts the side ofD
' bytecode almost in half.Possible solutions
Backwards Compatibility
I can't see any backwards compatibility issues here.
The text was updated successfully, but these errors were encountered: