callconv: fix mips64 aggregate argument passing for C FFI

[chenx97]

MIPS64 needs to put a padding argument before an aggregate argument when
this argument is in an odd-number position, starting from 0, and has an
alignment of 16 bytes or higher, e.g.
void foo(int a, max_align_t b); is the same as
void foo(int a, long _padding, max_align_t b);

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[chenx97]

r? @workingjubilee

[rustbot]

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

[chenx97]

r? @petrochenkov

[petrochenkov]

r? @workingjubilee
I've stolen one PR from workingjubilee's queue instead.

[rustbot]

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

[workingjubilee]

Fair trade.

[workingjubilee]

@chenx97 re: your PR message: a is an alignment, and a is (8 < a) && (a <= 16)? Since 8 is not less than a if a == 8, then doesn't that mean a == 16? Or do you mean let 8 | 16 = a;?

[workingjubilee]

So we take the max of align_of::<ArgType>() and align_of::<i64>(), guaranteeing it is at least align_of::<i64>(), and then we take the minimum of align_of::<i128>() and align_of::<ArgType>(), guaranteeing it is no more than align_of::<i128>()...

So, is there a reason this isn't just Ord::clamp(arg.layout.align.abi, dl.i64_align, dl.128_align)?

And then we ask if the offset is aligned to this? ... but we're changing the alignment so that u8, u16, etc. don't align...? You can easily convince me this PR is correct for MIPS, but I'm not sure how much this makes sense with respect to the PR description.

[chenx97]

So, is there a reason this isn't just Ord::clamp(arg.layout.align.abi, dl.i64_align, dl.128_align)?

There is no reason other than that this line comes from existing code in mips.rs:28. I'll update this patch accordingly.

but we're changing the alignment so that u8, u16, etc. don't align...?

The offset starts from 0 and only increments in an aligned manner, and u8, u16 and u32 are always as aligned as u64: *offset = offset.align_to(align) + size.align_to(align);

You can easily convince me this PR is correct for MIPS, but I'm not sure how much this makes sense with respect to the PR description.

In that case, I need help with improving my description and commit message.

[workingjubilee]

Well, usually when I note a value is in a range, even though it's a commit message or PR, I deliberately use Rust's range syntax and say it's in the range instead of < or <=, because I make mistakes like the one you made if I don't.

Similar to mips, mips64 also adds a padding register when an aggregate argument is not passed with an aligned offset,

I do not think "add a padding register when an aggregate argument is not passed with an aligned offset" is quite right. That makes it sound a bit like when you pass a 1-byte struct, it uses 9 bytes, that byte plus an entire register! It's more like, "pads aggregates up to the 64-bit register size", right?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.