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

[Trevor Gross via cfe-commits]

================
@@ -3450,10 +3448,31 @@ ABIArgInfo WinX86_64ABIInfo::classify(QualType Ty, unsigned &FreeSSERegs,
 
       // Mingw64 GCC returns i128 in XMM0. Coerce to v2i64 to handle that.
       // Clang matches them for compatibility.
-      // NOTE: GCC actually returns f128 indirectly but will hopefully change.
-      // See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054#c8.
-      return ABIArgInfo::getDirect(llvm::FixedVectorType::get(
-          llvm::Type::getInt64Ty(getVMContext()), 2));
+      if (BT->getKind() == BuiltinType::Int128 ||
+          BT->getKind() == BuiltinType::UInt128)
+        return ABIArgInfo::getDirect(llvm::FixedVectorType::get(
+            llvm::Type::getInt64Ty(getVMContext()), 2));
+
+      // Mingw64 GCC returns f128 via sret, and Clang matches that for
+      // compatibility. This mirrors the X86 backend's CanLowerReturn logic.
+      if (BT->getKind() == BuiltinType::Float128) {
+        auto IsWin64F128StackCC = [this](unsigned CC) -> bool {
+          switch (CC) {
+          case llvm::CallingConv::Win64:
+            return true;
+          case llvm::CallingConv::C:
----------------
tgross35 wrote:

> And given the name, here it kind of would make sense for GCC to pick passing/returning via vector registers?

I haven't looked at what this code does but my assumption is yes, for vectorcall f128 should ideally be returned in xmm0 (like the C convention today) and passed that way too (unlike the C convention)

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