Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--optimize should not trigger compilation if no optimized output is requested #15062

Open
cameel opened this issue Apr 26, 2024 · 0 comments
Open
Labels
high impact Changes are very prominent and affect users or the project in a major way. low effort There is not much implementation work to be done. The task is very easy or tiny. must have Something we consider an essential part of Solidity 1.0.
Milestone

Comments

@cameel
Copy link
Member

cameel commented Apr 26, 2024

Abstract

Currently just using the --optimize option alone triggers optimization, even if the user does not request any outputs which would make the effect of optimization actually observable, like --bin or --ir-optimized. The compiler should not run the optimizer in such cases.

Motivation

The output of solc --optimize --ir is identical to solc --ir and it could be just as fast, but instead it takes as much time as solc --optimize --ir-optimized.

The reason it matters is two-stage compilation, which is a mechanism we're soon going to be recommending as a way to parallelize compilation. Passing in the --optimize flag to the first stage is necessary to get correct metadata in cases where the optimization will only be performed by the second stage. For example, if the output of solc --ir is passed as input to solc --strict-assembly --optimize --bin, the metadata will say that the contract was not optimized. To get correct metadata the first command must be changed to solc --optimize --ir but currently this results in both stages performing the optimization, which doubles the compilation time and defeats the purpose.

Steps to reproduce

This can be easily observed when compiling a contract like chains.sol, where optimization takes a lot of time:

time solc test/benchmarks/chains.sol --ir
real    0m0.272s
user    0m0.232s
sys     0m0.020s
time solc test/benchmarks/chains.sol --ir --optimize
real    0m22.785s
user    0m22.616s
sys     0m0.070s
time solc test/benchmarks/chains.sol --ir --optimize --ir-optimized
real    0m22.515s
user    0m22.346s
sys     0m0.043s

Implementation notes

I think that --ir is actually the only output which exposes unoptimized artifacts (though we should check to make sure). If that's the case, internally it would be enough to extend the mechanism triggering enableIRGeneration() to have separate flags for optimized and unoptimized IR.

Otherwise, we might consider splitting the "compilation successful" state into into distinct "codegen successful" and "optimization successful" states in CompilerStack::State.

@cameel cameel added low effort There is not much implementation work to be done. The task is very easy or tiny. high impact Changes are very prominent and affect users or the project in a major way. must have Something we consider an essential part of Solidity 1.0. labels Apr 26, 2024
@cameel cameel added this to the 0.8.26 milestone Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high impact Changes are very prominent and affect users or the project in a major way. low effort There is not much implementation work to be done. The task is very easy or tiny. must have Something we consider an essential part of Solidity 1.0.
Projects
Development

No branches or pull requests

1 participant