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