--optimize
should not trigger compilation if no optimized output is requested
#15062
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
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 tosolc --ir
and it could be just as fast, but instead it takes as much time assolc --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 ofsolc --ir
is passed as input tosolc --strict-assembly --optimize --bin
, the metadata will say that the contract was not optimized. To get correct metadata the first command must be changed tosolc --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
time solc test/benchmarks/chains.sol --ir --optimize
time solc test/benchmarks/chains.sol --ir --optimize --ir-optimized
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 triggeringenableIRGeneration()
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
.The text was updated successfully, but these errors were encountered: