[clang] [llvm] [X86][Windows] Return `fp128` on the stack (PR #204887)

[Reid Kleckner via cfe-commits]

================
@@ -3,10 +3,10 @@
 // __float128 is unsupported on MSVC
 
 __float128 fp128_ret(void) { return 0; }
-// CHECK-GNU64: define dso_local <2 x i64>  @fp128_ret()
+// CHECK-GNU64: define dso_local fp128 @fp128_ret()
----------------
rnk wrote:

I would really prefer to have the frontend emit sret returns directly, even if we retain the LLVM-side sret demotion to make synthesized library calls work.

Something I worry about here is a C++ fp128 method return, especially in the MSVC ABI, where they always swap `this` and `sret`. If we rely on the backend to do this for us, we'll get it wrong, and we'll pass the `sret` pointer in RCX instead of RDX.

There's no MSVC ABI compatibility concern, but I wouldn't want to break that invariant if Clang is in the Microsoft ABI handshaking with itself. I would really rather have the frontend be explicit, even if that force Rust to reimplement more ABI lowering logic, a well-known pain point.

It's also probably easier to get the debug info right, get NRVO right, etc. When you model where things are actually stored in memory in IR, you usually get better results out of the optimizer.

https://github.com/llvm/llvm-project/pull/204887