Ensure floats are returned losslessly by the Rust ABI on 32-bit x86

[beetrees]

Solves #115567 for the (default) "Rust" ABI. When compiling for 32-bit x86, this PR changes the "Rust" ABI to return floats indirectly instead of in x87 registers (with the exception of single f32s, which this PR returns in general purpose registers as they are small enough to fit in one). No change is made to the "C" ABI as that ABI requires x87 register usage and therefore will need a different solution.

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
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

[compiler-errors]

Changes lgtm, but I'm not an ABI expert

[compiler-errors]

so let's get another look at it

r? compiler

[Nadrieril]

Not an ABI expert either

r? compiler

[fmease]

Looks reasonable to me, too. I'm also not an expert on this matter ^^'.
@RalfJung, could you help us out?

[beetrees]

I've added a commit to update platform-support.md to reflect the current state of #115567 after this PR (I had to rebase to avoid conflicts in platform-support.md). I also fixed the issue number to point to the correct issue.

[RalfJung]

Looks reasonable to me, too. I'm also not an expert on this matter ^^'. @RalfJung, could you help us out?

My name appears in these issues as I gained just enough knowledge to identify that we have a problem, but I don't feel confident to approve any changes to our ABI, sorry.

With my limited knowledge however, this change does make a lot of sense. And it's a lot simpler than what I thought was necessary to do this. Very nice!

So... who is an ABI expert? @bjorn3, @nikic and @eddyb are the first people coming to my mind.

(Maybe we should have some sort of dedicated ABI expert ping group. It would be really good to have some people in charge of ABI-related questions.)

[programmerjake]

I guess it can be left for a followup, but if SSE2 is available, I think f32/f64 should be returned in xmm0 instead of in memory, since the XMM registers are where all the math is done anyway. This can be done by setting the inreg LLVM parameter attribute on the return type:

https://github.com/llvm/llvm-project/blob/575a6483062b8a77b35f48589b2acc1020195ac7/llvm/lib/Target/X86/X86CallingConv.td#L300-L304

[beetrees]

@programmerjake See #115919 - currently blocked on #116584. I agree it would be a good future improvement once the target feature issues have been sorted out.

[beetrees]

Picking one of the people mentioned by @RalfJung earlier:

r? @bjorn3

[bjorn3]

I don't have time to review this for the next two weeks at least unfortunately.

[beetrees]

No worries. I'll try someone else.

r? @nikic

[bors]

⌛ Testing commit cae9d48 with merge c2437cb...

[rust-log-analyzer]

The job x86_64-msvc-ext failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[beetrees]

error: failed to remove file `C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe`

Caused by:
  Access is denied. (os error 5)

Error appears to be spurious.

[Kobzol]

@bors r=nikic,workingjubilee

[bors]

💡 This pull request was already approved, no need to approve it again.

• This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.
• There's another pull request that is currently being tested, blocking this pull request: [do not merge] Testing Windows CI #127373

[bors]

📌 Commit cae9d48 has been approved by nikic,workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit cae9d48 with merge c6727fc...

[bors]

☀️ Test successful - checks-actions
Approved by: nikic,workingjubilee
Pushing c6727fc to master...

[rust-timer]

Finished benchmarking commit (c6727fc): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-2.6%, -2.6%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 703.434s -> 705.609s (0.31%)
Artifact size: 328.58 MiB -> 328.61 MiB (0.01%)