3

Looking at the evmjit code I noticed that the LLVM optimizer is actually used right before execution of a contract by the virtual machine. I have also noticed that the Solidity compiler has its own optimizer that optimizes bytecode.

Therefore, I was wondering ... what is the benefit of having a bytecode optimizer in the Solidity compiler vs relying completely on the LLVM optimizer in the virtual machine ?

1

Regardless of how a contract is executed, it's the EVM's accounting that matters.

The protocol doesn't know if you're executing a contract on x86, a ARM7, a 6502, or pen and paper. What it does know is how much each step in the EVM costs, which is the same regardless. Solidity's optimization, by optimizing the EVM-level code, makes contracts cheaper in gas. Any client-side optimizer makes contracts cheaper in physical computer resources.

  • That's what I thought initially. However, my understanding is that gas is actually computed at runtime (as the contract executes) and the EVM injects gas functions into the llvm-ir. So essentially - and correct me if I'm wrong - an llvm optimization could have a direct impact on gas just like a bytecode optimization in the Solidity compiler. I see though, that such an optimization in llvm might be more complex to implement since operations are now much more fine-grained .... so my hypothesis right now is that this is why there are two optimizers. Does that make sense ? – Than21 Apr 12 '17 at 14:22
  • I'm not sure how the JIT works in this particular case, but nonetheless: Any client-side optimization still can't affect the gas used, because the EVM is the same for everyone, regardless of how they implement it. Think of it this way: an optimized client and one without an optimizer (or a different one) have to get the same result for a transaction's execution, or the blockchain would fork between them. – Matthew Schmidt Apr 12 '17 at 19:39
0

My conclusion on this is that it's definitely possible to perform the same optimization in LLVM during execution and reduce Gas in theory. However, this is probably an intractable problem in practice due to the nature of the LLVM IR, i.e., it is just too low level for this job. A different compiler abstraction is needed in order to make such optimizations easier to implement and more robust and the Solidity compiler does exactly that. The IR of the Solidity optimizer though doesn't seem well-defined to me and rather ad-hoc. I was wondering if there is a plan to improve that in the future and build an optimizer that allows third-party optimizer modules (similar to LLVM).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.