[YulOpti] Evaluate keccak256 whenever possible

[hrkrshnn]

For example, if we have a storage variable uint[] a, the following is the optimized IR code for computing arr[10] = 5:

Here value of _1 is 0.

mstore(_1, 0x01)
sstore(add(keccak256(_1, 0x20), 0x0a), 0x05)

It would be nice if we could compute this hash, and also avoid the mstore.

Was bought by in the forum by @frangio https://forum.soliditylang.org/t/enable-disable-language-features-to-save-gas/84/20

[chriseth]

The libevmasm optimizer can do it. I think it should actually compute it in this case.

[chriseth]

In the end, this is a task for the mload resolver (eliminate the keccak) and the redundant store eliminator (eliminate the mstore as soon as the keccak is gone).

[hrkrshnn]

Even the old optimizer isn't able to do this:

      0x00
      swap2
      dup3
      mstore
      0x20
      swap1
      swap2
      keccak256
      add
        /* "<stdin>":69:78  x[10] = 5 */
      sstore
        /* "<stdin>":28:82  function f() public returns (uint a) {... */

[chriseth]

Maybe because it deems the result suboptimal?

[hrkrshnn]

I think the old optimizer is not able to do it because of an intermediate jump:

    tag_5:
        /* "<stdin>":57:63  uint a */
      0x00
        /* "<stdin>":77:78  5 */
      0x05
        /* "<stdin>":69:70  x */
      0x00
        /* "<stdin>":71:73  10 */
      0x0a
        /* "<stdin>":69:74  x[10] */
      dup2
      sload
      dup2
      lt
      tag_9
      jumpi
      mstore(0x00, 0x4e487b7100000000000000000000000000000000000000000000000000000000)
      mstore(0x04, 0x32)
      revert(0x00, 0x24)
    tag_9:
      0x00
      swap2
      dup3
      mstore
      0x20
      swap1
      swap2
      keccak256
      add
        /* "<stdin>":69:78  x[10] = 5 */
      sstore
        /* "<stdin>":28:82  function f() public returns (uint a) {... */
      swap1
      jump	// out

[chriseth]

Ah, that is probably true!

[github-actions]

Hi everyone! This issue has been closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

[frangio]

I believe this should remain open, it's a concrete optimization that should be implemented.

[cameel]

We have a lot of these optimizations in the backlog and we're starting to think that having an issue for each one is not the best way to keep track of them. May don't have enough detail to just hand the task to someone for implementation. Some of them are even mutually exclusive. It's just a messy wishlist right now and a lot of it may end up never being implemented.

@ekpyron suggested creating some document to track them instead. Maybe we should have issues only for more concrete stuff we actually intend to implement in the near future.

But since you're clearly interested in this one, I'll reopen it for the time being just so that it remains more visible.

[frangio]

I don't have a special interest in this one, but I definitely have an interest in optimizations in general. I commented because I felt that if this was closed it would get lost. I support whatever you consider the most effective way to keep track of optimization opportunities.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.