Unsigned Arithmetic Gas Cost

Under solc 0.8.19 (EVM version "Paris"), using non-constant operands, my measurement shows:


Question 1:

As you can see, when viaIR is disabled, unchecked division (40) is cheaper than checked division (72) despite the fact that no overflow or underflow can ever take place.

The difference may lie in the fact that upon division by zero, checked division refunds the caller with the remaining gas (revert), while unchecked division doesn't (assert).

But I'm pretty sure that on recent EVM versions, both revert and assert refund the caller with the remaining gas.

Does anybody happen to know the benefit in using checked division over unchecked division?

Question 2:

As you can see, unchecked division is cheaper with viaIR disabled (40) vs with viaIR enabled (56). Would you happen to know the reason for that?

Did you have optimizations enabled?

The difference may be because the compiler emits a custom Panic code for division by zero. I don't know if it also does it in unchecked mode. You should inspect the bytecode.

This (the table in my question) illustrates the gas cost with and without viaIR.

Compiler optimization was set as it is by default (enabled, with runs=200).

But compiler optimization wouldn't impact the gas cost of the pure operation anyway, when that operation is measured standalone.

For example, in order to measure the gas cost of addition, I use:

function add(uint256 x, uint256 y) external returns (uint256 z) {
    uint256 gasLeft = gasleft();
    z = x + y;
    gasUsed = gasLeft - gasleft();

Where gasUsed is a public variable in my test contract.
From an offchain script, I deploy the contract, execute the function, and read the value of that variable.

I believe that the compiler emits:

  • The opcode associated with revert, when a checked division by zero is executed
  • The opcode associated with assert, when an unchecked division by zero is executed

But that's kind of irrelevant, since I'm obviously measuring the gas cost of a division which completes successfully (i.e., NOT by zero).