We currently don't support this optimization and it's especially an issue for calls involving i64: the micro-benchmark below is 4-5x slower with Warp. I have a WIP patch to port this to Warp.

var i1 = new WebAssembly.Instance(new WebAssembly.Module(wasmTextToBinary(`(module (func) (func (param i64) (result i64) (i64.add (local.get 0) (i64.const 1))) (func) (export "f" (func 1)))`)));
function test() {
    var f = i1.exports.f;
    var t = dateNow();
    var res = 0n;
    for (var i = 0; i < 100_000_000; i++) {
        res = f(res);
    }
    print(dateNow() - t);
    print(res);
}
test();

Yeah, not having this would be a (bad?) regression.

Mostly based on IonBuilder::inlineWasmCall. Because there's a post-conversion
instruction for i64 => BigInt, we unfortunately have to relax some assertions
around resume points.

This caught some isEffectful instructions that were marked isMovable. That doesn't
really make sense, but this also doesn't fix any actual issues because optimizations
check both.

Depends on D92579

https://hg.mozilla.org/mozilla-central/rev/94aa4cd72aed
https://hg.mozilla.org/mozilla-central/rev/000f531b8ba8