My question may be a bit broad and could be summarized as: What’s the current state of YUL?
Like, to what extent is YUL already used when compiling solidity code? Since
--optimize-yul
is deprecated and the help says--optimize
enables the YUL optimizer it seems that YUL is already integrated in the default compilation pipeline. I can imagine it is more nuanced and would be interested to understand the current state of the transition to YUL better.Also, looking through solidity’s Github issues I noticed proposals to add inheritance, structs, tuples etc to YUL. These are proposals / feature requests and I understand that many potential features may still be undecided but I wonder how many higher level features the team is planning to add to YUL? Is the plan to keep YUL a lower level language used as an intermediate language or do you foresee YUL being used as a language to implement contracts directly?
At the current stage, Yul is used heavily for internal routines like the ABI coder, overflow-checked arithmetic and everything more complicated that has been added over the course of the last year. You can access these routines as an isolated file when requesting the evm.bytecode.generatedSources
or evm.deployedBytecode.generatedSources
fields via Standard-Json.
Apart from internal routines, we also re-wrote the entire Solidity code generator to go through Yul. Since the beginning of the year, we have 100% coverage on our semantic tests. You can request the generated yul code using solc --ir
or solc --ir-optimized --optimize
. This only exports the Yul code. To switch over the whole compilation pipeline, you can use solc --experimental-via-ir
.
We are still working on carrying all metadata and debugging information across the new pipeline and we would also like to improve the optimizer so that the new code is cheaper in most cases and at least not much more expensive in rare cases. We are currently conducting gas tests to get a good picture.
If anyone has Solidity code that is already compiling in 0.8.x, we would be grateful for a pointer so that we can tune the optimizer for “real world” code.
There have been some discussion in connection to YulPlus but most of the proposals are on ice. One thing we would still like to improve is the memory management. If you make memory management more explicit, it is easier to move stack variables to memory or reuse unused memory.
Yul’s purpose is to be an intermediate or assembly language that is auditable It can be written by hand (see inline assembly), but should usually be generated by other programs.