================
@@ -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:
----------------
folkertdev wrote:
We currently pass `f128` via XMM registers (below xmm0 contains %a, rdx
contains %p):
```llvm
define x86_vectorcallcc void @"\01pass_vectorcall"(fp128 %a, ptr %p) {
; WIN-LABEL: pass_vectorcall:
; WIN: # %bb.0:
; WIN-NEXT: movaps %xmm0, (%rdx)
; WIN-NEXT: retq
;
; LINUX-LABEL: pass_vectorcall:
; LINUX: # %bb.0:
; LINUX-NEXT: movaps %xmm0, (%rdx)
; LINUX-NEXT: retq
store fp128 %a, ptr %p
ret void
}
```
The current code also returns via xmm0 for vectorcall.
So yeah, we can discuss this but it seems quite reasonable? And it can be
changed later if there is something we'd want to be compatible with that makes
a different choice.
https://github.com/llvm/llvm-project/pull/204887
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
