improve reentrancy guard

[0age]

No description provided.

[Saw-mon-and-Natalie]

These sloads get hoisted out of the for loop by the LoopInvariantCodeMotion yul optimization since its value is independent of each iteration:

For example the compiled ir code for assertAcceptingNativeTokens() looks like:

function fun_assertAcceptingNativeTokens()
{
  /// @src 51:14266:14287  "_tstoreInitialSupport"
  let _1 := loadimmutable("53400")
  /// @src 51:14377:18103  "assembly {..."
  let _2 := 2459889172
  let usr$reentrancyGuard := sload(_2)
  let _3 := iszero(usr$reentrancyGuard)
  let _4 := iszero(eq(usr$reentrancyGuard, 3))
  for { } 1 { }
  {
      if _1
      {
          if iszero(eq(tload(_2), 2))
          {
              mstore(0, 2786847216)
              mstore(32, callvalue())
              revert(28, 36)
          }
          break
      }
      if _3
      {
          if iszero(eq(tload(_2), 2))
          {
              mstore(0, 2786847216)
              mstore(32, callvalue())
              revert(28, 36)
          }
          break
      }
      if _4
      {
          mstore(0, 2786847216)
          mstore(32, callvalue())
          revert(28, 36)
      }
      break
  }
}

So sload will be used even if transient storage is already available during deployment.

[Saw-mon-and-Natalie]

same comment applies to other for loops of similar form in this and other contracts.

[Saw-mon-and-Natalie]

seems like setReentrancyGuard(...) is not affected but we have 2 yul functions fun_setReentrancyGuard_X() and fun_setReentrancyGuard_Y() where _ENTERED_XSTORE is specialised. So in total 3 setReentrancyGuard(...) functions. This probably comes from:

1. setReentrancyGuard(false) in _prepareBasicFulfillmentFromCalldata
2. setReentrancyGuard(true) in _validateOrdersAndPrepareToFulfill

[Saw-mon-and-Natalie]

The specialisation might make the runtime code a bit cheaper, but it would increase the deployment gas cost and deployed byte code size.

[0age]

So do we have a way to coerce the compiler to avoid the sload when not required here?

[0age]

pushed a fix for the hoisting issue and verified against the IR output; given we have the runtime code headroom we may as well leave the specialization in for now @Saw-mon-and-Natalie

2c7e977

[Saw-mon-and-Natalie]

@0age another solution would have been to remove that optimisation step from the optimisation sequence LoopInvariantCodeMotion M