explicit tail calls: support indirect arguments

[folkertdev]

tracking issue: #112788

After discussion in #144855, I was wrong and it is actually possible to support tail calls with PassMode::Indirect { on_stack: false, .. } arguments.

Normally an indirect argument with on_stack: false would be passed as a pointer into the caller's stack frame. For tail calls, that would be unsound, because the caller's stack frame is overwritten by the callee's stack frame.

Therefore we store the argument for the callee in the corresponding caller's slot. Because guaranteed tail calls demand that the caller's signature matches the callee's, the corresponding slot has the correct type.

To handle cases like the one below, the tail call arguments must first be copied to a temporary, and can only then be copied to the caller's argument slots.

// A struct big enough that it is not passed via registers.
pub struct Big([u64; 4]);

fn swapper(a: Big, b: Big) -> (Big, Big) {
    become swapper_helper(b, a);
}

---

I'm not really familiar with MIR and what tricks/helpers we have, so I'm just cobbling this together. Hopefully we can arrive at something more elegant.

[folkertdev]

I've kept the span_bug! for now.

It looks like a fix for x86 might get cherry-picked into LLVM 22. If so, I think that is enough support to allow this variant too. At that point riscv would be the next most commonly used target that would miscompile.

[folkertdev]

@bors try=x86_64-msvc-1,x86_64-msvc-2

[rust-bors]

Unknown command "try". Run @bors help to see available commands.

[folkertdev]

@bors try job=x86_64-msvc-1,x86_64-msvc-2

[rust-bors]

💔 Test for e8cb9bb failed: CI. Failed job:

• try - x86_64-msvc-1 (web logs, enhanced plaintext logs)

[folkertdev]

@bors try job=x86_64-msvc-1,x86_64-msvc-2

[rust-bors]

☀️ Try build successful (CI)
Build commit: 282e2c8 (282e2c837faf975d875d5007dcbbdb5567a62f41, parent: b5c2a0fc0ac851e83ef943e3a2b90c1abab06baa)

[folkertdev]

This seems to work, though we should probably run a bunch of try jobs once the code looks good.

r? @WaffleLapkin

[rustbot]

WaffleLapkin is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[bjorn3]

This shouldn't be a deref. arg.val is not a pointer to the argument value, but an operand representing the value itself. Rather I think it is always a OperandValue::Ref(place) where place is the location that the argument is stored at. arg.val.deref() would incorrectly treat the argument as a pointer itself. Would you mind adding a test for tail calling with a u128 argument on Windows?

[folkertdev]

I added

  assert_eq!(swapper(i128::MIN, i128::MAX), (i128::MAX, i128::MIN));

below, which succeeded earlier. But I'll add a minicore/codegen test for this then, just to be sure.

[folkertdev]

I missed the extern "C" bit. The deref did seem to generate the expected code, but I suspect matching on Ref will be more helpful in catching bugs, so I'm using that now.

[folkertdev]

this swapping is a little unfortunate of course. I suspect this is a very rare pattern in practice though, so we just need a correct implementation, not necessarily the most optimal one from the get-go.