exported trampolines: should gas be charged for function arguments?

[nagisa]

With a traditional wasm-to-wasm function call the caller will implicitly pay for the function arguments by setting up the operand stack in a specific way for the callee:

(module
  (func $a
     (call $b (i32.const 42) (i64.const 24))
  )
  (func $b (param i32 i64))
)

(assert_instrumented_gas (module
  (import "" "gas" (func $gas (param i64)))

  (func $a 
     (call $gas (i64.const 3)) (; 2 const instructions and 1 call ;)
     (call $b (i32.const 42) (i64.const 24))
  )
  (func $b (param i32 i64))
))

The same is true for VM-to-host calls. However, none of this operand stack business occurs when calling VM functions from within the host (or re-exported host functions), so it is possible that in example like this:

(module
  (func (export "main") (param i32 i64) (local i32 i64 i32 i64 i32))
)

(assert_instrumented_gas (module
  (import "" "gas" (func $gas (param i64)))

  (func $original_main (param i32 i64) (local i32 i64 i32 i64 i32))
  (func (export "main") (param $p1 i32 $p2 i64)
    (; calling `$original_main` will initialize 5 locals to 0 ;)
    (call $gas (i64.const 5))
    (;>>> setting up arguements has not been paid yet... <<<;)
    (call $original_main (local.get $p1) (local.get $p2))
  )
))

Instrumentation would fail to account for the potentially significant amount of work.

For nearcore this is not super relevant as it only allows host-to-VM calls of exported functions without params or return values. Question is: in the use-cases where the parameters are allowed, should we charge gas for each parameter here, or should we not? Following the concept of “charge gas before operations”, the gas for this sort of stuff should be paid for before the host-to-VM call is even executed, so that'd be a vote against doing anything here. However, if we punt on this and leave the host to deal with the problem, then it makes the instrumentation not very hermetic/self-contained.