================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
