TIP: Check failed: expect == mt.Call() (2 vs. 0)

Describe the bug
This issue shows up when using the rebase-to-tip branch (#273). Several cases fail with this same error (see related cases below).

To Reproduce
Steps to reproduce the behavior:

1. Checkout rebase-to-tip
2. Follow standard build procedure
3. Run the test:

riscv64.sim/cctest test-multiple-return/ReturnLastValueInt64 --random-seed=-1445372902 --nohard-abort --enable-slow-asserts --verify-heap --testing-d8-test-runner

Expected behavior
I expected this test to pass.

Errors/Logs

#
# Fatal error in ../../test/cctest/compiler/test-multiple-return.cc, line 301
# Check failed: expect == mt.Call() (2 vs. 0).
#
#
#
#FailureMessage Object: 0x7ffc9dade140
==== C stack trace ===============================

    /v8/out/riscv64.sim/cctest(+0x4057313) [0x55d5cd9ac313]
    /v8/out/riscv64.sim/cctest(+0x40562ed) [0x55d5cd9ab2ed]
    /v8/out/riscv64.sim/cctest(+0x3dba483) [0x55d5cd70f483]
    /v8/out/riscv64.sim/cctest(+0x12cdd90) [0x55d5cac22d90]
    /v8/out/riscv64.sim/cctest(+0x1259efe) [0x55d5cabaeefe]
    /v8/out/riscv64.sim/cctest(+0x125be7e) [0x55d5cabb0e7e]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f4c3e791b97]
    /v8/out/riscv64.sim/cctest(_start+0x2a) [0x55d5cabaec6a]
Aborted (core dumped)

Probably related failures:

• cctest/test-multiple-return/ReturnLastValueFloat32
• cctest/test-multiple-return/ReturnLastValueFloat64
• cctest/test-multiple-return/ReturnMultipleFloat32
• cctest/test-multiple-return/ReturnMultipleInt32
• cctest/test-multiple-return/ReturnMultipleFloat64
• cctest/test-multiple-return/ReturnSumOfReturnsFloat32
• cctest/test-multiple-return/ReturnSumOfReturnsInt32
• cctest/test-multiple-return/ReturnSumOfReturnsFloat64
• cctest/test-multiple-return/ReturnMultipleInt64
• cctest/test-multiple-return/ReturnSumOfReturnsInt64
• wasm-api-tests/WasmCapiTest.MultiReturn
• mjsunit/wasm/multi-value
• mjsunit/wasm/return-calls
• wasm-spec-tests/func
• wasm-spec-tests/proposals/js-types/func
• wasm-spec-tests/proposals/reference-types/func

The problem is in this sequence of instructions:

   0x00dff2af052c   sd        s3, 16(fp)                                (53)    2 --> [addr: 7fc4c0fc3f00]
   0x00dff2af0530   mv        sp, fp                00007fc4c0fc3ef0    (54)
   0x00dff2af0534   ld        fp, 0(sp)             00007fc4c0fc3fc0    (55)
   0x00dff2af0538   ld        ra, 8(sp)             00000025521c3244    (56)
   0x00dff2af053c   addi      sp, sp, 16            00007fc4c0fc3f00    (57)
   0x00dff2af0540   ret                             0000000000000000    (58)
   0x0025521c3244   ld        a1, -184(fp)          0000000000000000    (59)    0 <-- [addr: 7fc4c0fc3f08]
   0x0025521c3248   sext.w    a0, a1                0000000000000000    (60)

The load at (60) should be loading from the address that is written to in (53), but it is off by 8. In the old build, which passes, the load uses an offset of -192, which looks like it would be correct here as well. It is unclear where this code is coming from. The code (from --print-all-code) has a label of:

 --- Code ---
 kind = STUB
 name = testing
 compiler = turbofan
 address = 0x25521c3141

This code in the test case:

    mt.Return(
        ToInt32(&mt, type,
                mt.AddNode(mt.common()->Projection(return_count - 1), call)));

becomes this assembly code:

   0x0025521c3244   ld        a1, -184(fp)          0000000000000000    (59)    0 <-- [addr: 7fc4c0fc3f08]
   0x0025521c3248   sext.w    a0, a1                0000000000000000    (60)

The offset is incorrect in that load, but I cannot figure out where it comes from.

I finally found the cause of this issue. It comes from CodeGenerator::AssembleArchInstruction:

    case kRiscvPeek: {
      int reverse_slot = i.InputInt32(0); // There was previously a 1 added to this value
      int offset =
          FrameSlotToFPOffset(frame()->GetTotalFrameSlotCount() - reverse_slot);