[clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[wangleiat]

Summary

Prior to this patch, paramter or return value whose type was a
structure containing empty structure members and fewer than three
floating-point members did not meet the calling convention.

With this patch, an empty struct will always be passed.

An empty struct type that is not non-trivial for the purposes of calls
will be treated as though it were the following C type:

struct {
  char c;
};

[xry111]

Blocking this as it's a deliberate decision made in D132285.

Is there any imperative reason we must really pass the empty struct? The C++ standard only treats struct {} as size 1 for the semantics of pointer comparison. While there is no pointers to registers, ignoring it in the register calling convention will make no harm.

And AFAIK it will be an undefined behavior attempting to (mis)use the padding space of/after the empty struct to pass any information.

[xry111]

Note that we are using the "de-facto" ABI throwing away this empty struct since the first release of GCC supporting LoongArch, and also Clang. So is there an imperative reason we must change it?

And IIUC we've agreed to revise the ABI since Apr 2022 for this, but unfortunately I've never got enough English skill to do the revision myself :(.

[wangleiat]

In D151298#4367163, @xry111 wrote:

Blocking this as it's a deliberate decision made in D132285.

Is there any imperative reason we must really pass the empty struct? The C++ standard only treats struct {} as size 1 for the semantics of pointer comparison. While there is no pointers to registers, ignoring it in the register calling convention will make no harm.

And AFAIK it will be an undefined behavior attempting to (mis)use the padding space of/after the empty struct to pass any information.

Our current modifications are closer to the description of Itanium C++ ABI, and we try to keep it consistent with the description of the calling convention under reasonable premise.

[xry111]

In D151298#4367215, @wangleiat wrote:

In D151298#4367163, @xry111 wrote:

Blocking this as it's a deliberate decision made in D132285.

Is there any imperative reason we must really pass the empty struct? The C++ standard only treats struct {} as size 1 for the semantics of pointer comparison. While there is no pointers to registers, ignoring it in the register calling convention will make no harm.

And AFAIK it will be an undefined behavior attempting to (mis)use the padding space of/after the empty struct to pass any information.

Our current modifications are closer to the description of Itanium C++ ABI, and we try to keep it consistent with the description of the calling convention under reasonable premise.

Hmm, could you provide a link to the section saying this in the Itanium C++ ABI?

I see it has some words about passing or returning an empty class, but there seems no words about passing a class containing an empty class.

And for our own psABI, it's easier to simply reword it (making it similar to the RISC-V psABI about passing args with FPRs) instead of modifying both Clang and GCC (causing the code of Clang and GCC more nasty, and both compilers slower, and we'll need to add a -Wpsabi warning at least in GCC too). And it already needs a reword considering empty arrays and zero-width bit-fields anyway.

[wangleiat]

In D151298#4367225, @xry111 wrote:

In D151298#4367215, @wangleiat wrote:

In D151298#4367163, @xry111 wrote:

Blocking this as it's a deliberate decision made in D132285.

Is there any imperative reason we must really pass the empty struct? The C++ standard only treats struct {} as size 1 for the semantics of pointer comparison. While there is no pointers to registers, ignoring it in the register calling convention will make no harm.

And AFAIK it will be an undefined behavior attempting to (mis)use the padding space of/after the empty struct to pass any information.

Our current modifications are closer to the description of Itanium C++ ABI, and we try to keep it consistent with the description of the calling convention under reasonable premise.

Hmm, could you provide a link to the section saying this in the Itanium C++ ABI?

http://itanium-cxx-abi.github.io/cxx-abi/abi.html#empty-parameters
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#emptty-return-values

I see it has some words about passing or returning an empty class, but there seems no words about passing a class containing an empty class.

It's possible that my understanding is incorrect. There is indeed no place to see how an empty class is passed, just like there is no documentation on how to pass class A { class B { char c;};};.

And for our own psABI, it's easier to simply reword it (making it similar to the RISC-V psABI about passing args with FPRs) instead of modifying both Clang and GCC (causing the code of Clang and GCC more nasty, and both compilers slower, and we'll need to add a -Wpsabi warning at least in GCC too). And it already needs a reword considering empty arrays and zero-width bit-fields anyway.

I'm sorry, I couldn't quite understand what you meant.

[xry111]

In D151298#4367349, @wangleiat wrote:

In D151298#4367225, @xry111 wrote:

In D151298#4367215, @wangleiat wrote:

In D151298#4367163, @xry111 wrote:

Blocking this as it's a deliberate decision made in D132285.

Is there any imperative reason we must really pass the empty struct? The C++ standard only treats struct {} as size 1 for the semantics of pointer comparison. While there is no pointers to registers, ignoring it in the register calling convention will make no harm.

And AFAIK it will be an undefined behavior attempting to (mis)use the padding space of/after the empty struct to pass any information.

Our current modifications are closer to the description of Itanium C++ ABI, and we try to keep it consistent with the description of the calling convention under reasonable premise.

Hmm, could you provide a link to the section saying this in the Itanium C++ ABI?

http://itanium-cxx-abi.github.io/cxx-abi/abi.html#empty-parameters
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#emptty-return-values

I see it has some words about passing or returning an empty class, but there seems no words about passing a class containing an empty class.

It's possible that my understanding is incorrect. There is indeed no place to see how an empty class is passed, just like there is no documentation on how to pass class A { class B { char c;};};.

I think the paragraph means:

class Empty {};
int test(Empty empty, int a);

Then we should put a into a1, not a0. And we are indeed doing so.

And for our own psABI, it's easier to simply reword it (making it similar to the RISC-V psABI about passing args with FPRs) instead of modifying both Clang and GCC (causing the code of Clang and GCC more nasty, and both compilers slower, and we'll need to add a -Wpsabi warning at least in GCC too). And it already needs a reword considering empty arrays and zero-width bit-fields anyway.

I'm sorry, I couldn't quite understand what you meant.

I mean now GCC and Clang have the same behavior, so it's easier to just document the behavior in our psABI doc instead of making both Clang and GCC rigidly following the interpretation of psABI (which is currently unclear about zero-sized fields now) anyway.

And the current behavior of GCC and Clang treating a class containing two floating-point members and some empty fields is same as RISC-V, so it's highly unlikely we are violating the C++ standard or IA64 C++ ABI (or the entire RISC-V ecosystem would be violating them). The only issue is our psABI is unclear about empty fields, and the easiest way to solve the issue is revising the psABI (maybe, just "borrowing" some paragraphs from RISC-V psABI if there is no copyright issue).

[wangleiat]

I think the paragraph means:

class Empty {};
int test(Empty empty, int a);

Then we should put a into a1, not a0. And we are indeed doing so.

yes. with this patch, a will be passed with a1 register.

I mean now GCC and Clang have the same behavior, so it's easier to just document the behavior in our psABI doc instead of making both Clang and GCC rigidly following the interpretation of psABI (which is currently unclear about zero-sized fields now) anyway.

And the current behavior of GCC and Clang treating a class containing two floating-point members and some empty fields is same as RISC-V, so it's highly unlikely we are violating the C++ standard or IA64 C++ ABI (or the entire RISC-V ecosystem would be violating them). The only issue is our psABI is unclear about empty fields, and the easiest way to solve the issue is revising the psABI (maybe, just "borrowing" some paragraphs from RISC-V psABI if there is no copyright issue).

If we want to ignore empty structures, it is not enough to only modify psABI, because the current implementations of gcc and clang do not ignore empty structures in all cases. For example:

struct { struct{}; int i; }; // in this case, the empty struct is not ignored.
struct { struct{}; float f; }; // ignored.

Whether to ignore empty structures or not can affect the testing of gdb. @seehearfeel knows more details.

[xry111]

In D151298#4367458, @wangleiat wrote:

I think the paragraph means:

class Empty {};
int test(Empty empty, int a);

Then we should put a into a1, not a0. And we are indeed doing so.

yes. with this patch, a will be passed with a1 register.

I mean now GCC and Clang have the same behavior, so it's easier to just document the behavior in our psABI doc instead of making both Clang and GCC rigidly following the interpretation of psABI (which is currently unclear about zero-sized fields now) anyway.

And the current behavior of GCC and Clang treating a class containing two floating-point members and some empty fields is same as RISC-V, so it's highly unlikely we are violating the C++ standard or IA64 C++ ABI (or the entire RISC-V ecosystem would be violating them). The only issue is our psABI is unclear about empty fields, and the easiest way to solve the issue is revising the psABI (maybe, just "borrowing" some paragraphs from RISC-V psABI if there is no copyright issue).

If we want to ignore empty structures, it is not enough to only modify psABI, because the current implementations of gcc and clang do not ignore empty structures in all cases. For example:

struct { struct{}; int i; }; // in this case, the empty struct is not ignored.
struct { struct{}; float f; }; // ignored.

This is the same behavior as RISC-V. While attempting to pass a struct through FPRs, the empty field is ignored. But if passing through FPR does not work and it's passed through GPRs, the empty fields are not ignored:

https://godbolt.org/z/T1PKoxbYM

Whether to ignore empty structures or not can affect the testing of gdb. @seehearfeel knows more details.

I guess we should be able to fix it for GDB because they must have fixed it for RISC-V already.

[xry111]

In D151298#4367496, @xry111 wrote:

In D151298#4367458, @wangleiat wrote:

I think the paragraph means:

class Empty {};
int test(Empty empty, int a);

Then we should put a into a1, not a0. And we are indeed doing so.

yes. with this patch, a will be passed with a1 register.

I mean now GCC and Clang have the same behavior, so it's easier to just document the behavior in our psABI doc instead of making both Clang and GCC rigidly following the interpretation of psABI (which is currently unclear about zero-sized fields now) anyway.

And the current behavior of GCC and Clang treating a class containing two floating-point members and some empty fields is same as RISC-V, so it's highly unlikely we are violating the C++ standard or IA64 C++ ABI (or the entire RISC-V ecosystem would be violating them). The only issue is our psABI is unclear about empty fields, and the easiest way to solve the issue is revising the psABI (maybe, just "borrowing" some paragraphs from RISC-V psABI if there is no copyright issue).

If we want to ignore empty structures, it is not enough to only modify psABI, because the current implementations of gcc and clang do not ignore empty structures in all cases. For example:

struct { struct{}; int i; }; // in this case, the empty struct is not ignored.
struct { struct{}; float f; }; // ignored.

This is the same behavior as RISC-V. While attempting to pass a struct through FPRs, the empty field is ignored. But if passing through FPR does not work and it's passed through GPRs, the empty fields are not ignored:

https://godbolt.org/z/T1PKoxbYM

Whether to ignore empty structures or not can affect the testing of gdb. @seehearfeel knows more details.

I guess we should be able to fix it for GDB because they must have fixed it for RISC-V already.

@seehearfeel: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9f0272f8548164b024ff9fd151686b2b904a5d59

[wangleiat]

If we want to ignore empty structures, it is not enough to only modify psABI, because the current implementations of gcc and clang do not ignore empty structures in all cases. For example:

struct { struct{}; int i; }; // in this case, the empty struct is not ignored.
struct { struct{}; float f; }; // ignored.

This is the same behavior as RISC-V. While attempting to pass a struct through FPRs, the empty field is ignored. But if passing through FPR does not work and it's passed through GPRs, the empty fields are not ignored:

Yes, but our psABI still differs from RISC-V in the description of parameter passing, and it would be better to have consistent behavior regardless of whether there are floating points or not.

[xry111]

In D151298#4367620, @wangleiat wrote:

If we want to ignore empty structures, it is not enough to only modify psABI, because the current implementations of gcc and clang do not ignore empty structures in all cases. For example:

struct { struct{}; int i; }; // in this case, the empty struct is not ignored.
struct { struct{}; float f; }; // ignored.

This is the same behavior as RISC-V. While attempting to pass a struct through FPRs, the empty field is ignored. But if passing through FPR does not work and it's passed through GPRs, the empty fields are not ignored:

Yes, but our psABI still differs from RISC-V in the description of parameter passing, and it would be better to have consistent behavior regardless of whether there are floating points or not.

But it's easier to just modify the text of the ABI doc, in order to avoid an ABI incompatibility between different GCC of Clang versions (as GCC and Clang are only C++ compilers supporting LoongArch now).

[xen0n]

FYI, in the matching GCC patch discussion it was suggested that such a treatment wouldn't be necessary in principle.

[aaron.ballman]

Adding codegen code owners as reviewers.

[xry111]

If you are really determined to do this, then OK. I'm in a very bad
mood and I don't want to spend my mental strength on debating (esp. on a
corner case unlikely to affect "real" code) anymore.

But remember to add a entry in GCC 14 changes.html, and test this thing:

struct Empty {};

struct Something : Empty
{

double a, b;

};

If we are not careful enough we may introduce a ABI mismatch between -
std=c++14 and -std=c++17 here. See https://gcc.gnu.org/PR94383.

[rjmccall]

As far as I'm concerned as editor of the Itanium ABI, the ABI treatment of trivial-for-the-purposes-of-calls classes is purely a psABI matter, and the Itanium ABI's wording around empty classes is merely a suggestion if the psABI doesn't have more specific rules (because empty structs are normally invalid in C). Do what you think is best for your ABI.

[wangleiat]

We have decided to keep it unchanged. Thank you, everyone.

clang/docs/ReleaseNotes.rst

 Windows Support
 ^^^^^^^^^^^^^^^
 
 LoongArch Support
 ^^^^^^^^^^^^^^^^^
 
 - Patchable function entry (``-fpatchable-function-entry``) is now supported
   on LoongArch.
+- Fixed incorrect ABI lowering related to the handling of empty structs in C++
+  parameter passing.
 
 RISC-V Support
 ^^^^^^^^^^^^^^
 - Added ``-mrvv-vector-bits=`` option to give an upper and lower bound on vector
   length. Valid values are powers of 2 between 64 and 65536. A value of 32
   should eventually be supported. We also accept "zvl" to use the Zvl*b
   extension from ``-march`` or ``-mcpu`` to the be the upper and lower bound.
 - Fixed incorrect ABI lowering of ``_Float16`` in the case of structs

clang/lib/CodeGen/TargetInfo.cpp

 // Returns true if the struct is a potential candidate to be passed in FARs (and
 // GARs). If this function returns true, the caller is responsible for checking
 // that if there is only a single field then that field is a float.
 bool LoongArchABIInfo::detectFARsEligibleStructHelper(
     QualType Ty, CharUnits CurOff, llvm::Type *&Field1Ty, CharUnits &Field1Off,
     llvm::Type *&Field2Ty, CharUnits &Field2Off) const {
   bool IsInt = Ty->isIntegralOrEnumerationType();
   bool IsFloat = Ty->isRealFloatingType();
+  uint64_t Size = getContext().getTypeSize(Ty);
 
   if (IsInt || IsFloat) {
-    uint64_t Size = getContext().getTypeSize(Ty);
     if (IsInt && Size > GRLen)
       return false;
     // Can't be eligible if larger than the FP registers. Half precision isn't
     // currently supported on LoongArch and the ABI hasn't been confirmed, so
     // default to the integer ABI in that case.
     if (IsFloat && (Size > FRLen || Size < 32))
       return false;
     // Can't be eligible if an integer type was already found (int+int pairs
     // are not eligible).
     if (IsInt && Field1Ty && Field1Ty->isIntegerTy())
       return false;
     if (!Field1Ty) {
       Field1Ty = CGT.ConvertType(Ty);
       Field1Off = CurOff;
       return true;
     }
     if (!Field2Ty) {
       Field2Ty = CGT.ConvertType(Ty);
       Field2Off = CurOff;
       return true;
     }
     return false;
   }
 
+  if (isEmptyRecord(getContext(), Ty, true)) {
+    // Ignore the empty record in C mode.
+    if (Size == 0)
+      return true;
+    // Treat the empty record as char in C++ mode.
+    if (!Field1Ty) {
+      Field1Ty = llvm::Type::getInt8Ty(getVMContext());
+      Field1Off = CurOff;
+      return true;
+    }
+    if (!Field2Ty) {
+      Field2Ty = llvm::Type::getInt8Ty(getVMContext());
+      Field2Off = CurOff;
+      return true;
+    }
+    return false;
+  }
+
   if (auto CTy = Ty->getAs<ComplexType>()) {
     if (Field1Ty)
       return false;
     QualType EltTy = CTy->getElementType();
     if (getContext().getTypeSize(EltTy) > FRLen)
       return false;
     Field1Ty = CGT.ConvertType(EltTy);
     Field1Off = CurOff;
if (const ConstantArrayType *ATy = getContext().getAsConstantArrayType(Ty)) {
     return true;
   }
 
   if (const auto *RTy = Ty->getAs<RecordType>()) {
     // Structures with either a non-trivial destructor or a non-trivial
     // copy constructor are not eligible for the FP calling convention.
     if (getRecordArgABI(Ty, CGT.getCXXABI()))
       return false;
-    if (isEmptyRecord(getContext(), Ty, true))
-      return true;
     const RecordDecl *RD = RTy->getDecl();
     // Unions aren't eligible unless they're empty (which is caught above).
     if (RD->isUnion())
       return false;
     const ASTRecordLayout &Layout = getContext().getASTRecordLayout(RD);
     // If this is a C++ record, check the bases first.
     if (const CXXRecordDecl *CXXRD = dyn_cast<CXXRecordDecl>(RD)) {
       for (const CXXBaseSpecifier &B : CXXRD->bases()) {
ABIArgInfo LoongArchABIInfo::classifyArgumentType(QualType Ty, bool IsFixed,
   // copy constructor are always passed indirectly.
   if (CGCXXABI::RecordArgABI RAA = getRecordArgABI(Ty, getCXXABI())) {
     if (GARsLeft)
       GARsLeft -= 1;
     return getNaturalAlignIndirect(Ty, /*ByVal=*/RAA ==
                                            CGCXXABI::RAA_DirectInMemory);
   }
 
-  // Ignore empty structs/unions.
-  if (isEmptyRecord(getContext(), Ty, true))
-    return ABIArgInfo::getIgnore();
-
   uint64_t Size = getContext().getTypeSize(Ty);
 
+  // Empty records of size 0 are always ignored.
+  if (isEmptyRecord(getContext(), Ty, true) && Size == 0)
+    return ABIArgInfo::getIgnore();
+
   // Pass floating point values via FARs if possible.
   if (IsFixed && Ty->isFloatingType() && !Ty->isComplexType() &&
       FRLen >= Size && FARsLeft) {
     FARsLeft--;
     return ABIArgInfo::getDirect();
   }
 
   // Complex types for the *f or *d ABI must be passed directly rather than

clang/test/CodeGenCXX/LoongArch/abi-lp64d-empty-struct.cpp

 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --filter "^define" --version 2
 // RUN: %clang_cc1 -triple loongarch64 -target-feature +f -target-feature +d -target-abi lp64d \
 // RUN:   -emit-llvm %s -o - | FileCheck %s
 
 /// Treat the empty struct as char in C++ mode (sizeof(empty_s) = 1).
 /// If the empty struct is a struct's member, will be treated as
 /// fixed-point member.
 /// WOA: Bit width of the argument.
-/// FIXME: Empty struct is always passed or returned in C++ mode.
 
 /// 1. 0 < WOA <= GRLEN
 /// 1.a. Only fixed-point members.
 
 struct empty_s {};
-// CHECK-LABEL: define dso_local void @_Z12empty_struct7empty_s
-// CHECK-SAME: () #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local i64 @_Z12empty_struct7empty_s
+// CHECK-SAME: (i64 [[E_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_s empty_struct(struct empty_s e) {
   return e;
 }
 
 struct empty_char_s {
   struct empty_s e;
   char c;
 };

 /// 1.c. Both fixed-point and floating-point members.
 /// 1.c.i. Multiple fixed-point members.
 
 struct empty_char_float_s {
   struct empty_s e1;
   char c;
   float f32;
 };
-// CHECK-LABEL: define dso_local { i8, float } @_Z23empty_char_float_struct18empty_char_float_s
-// CHECK-SAME: (i8 [[TMP0:%.*]], float [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local i64 @_Z23empty_char_float_struct18empty_char_float_s
+// CHECK-SAME: (i64 [[S_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_char_float_s empty_char_float_struct(struct empty_char_float_s s) {
   return s;
 }
 
 /// 1.c.ii. One fixed-point member.
 
 struct empty_float_s {
   struct empty_s e;
   float f32;
 };
-// CHECK-LABEL: define dso_local float @_Z18empty_float_struct13empty_float_s
-// CHECK-SAME: (float [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { i8, float } @_Z18empty_float_struct13empty_float_s
+// CHECK-SAME: (i8 [[TMP0:%.*]], float [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_float_s empty_float_struct(struct empty_float_s s) {
   return s;
 }
 
 struct float_empty_s {
   float f32;
   struct empty_s e;
 };
 
-// CHECK-LABEL: define dso_local float @_Z18float_empty_struct13float_empty_s
-// CHECK-SAME: (float [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { float, i8 } @_Z18float_empty_struct13float_empty_s
+// CHECK-SAME: (float [[TMP0:%.*]], i8 [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct float_empty_s float_empty_struct(struct float_empty_s s) {
   return s;
 }
 
 /// 2. GRLEN < WOA <= 2*GRLEN
 
 /// 2.a. Only fixed-point members.
 struct empty_long_s {

 /// 2.c. Both fixed-point and floating-point members.
 /// 2.c.i. The structure has one floating-point member and only one fixed-point
 /// member.
 
 struct empty_double_s {
   struct empty_s e;
   double f64;
 };
-// CHECK-LABEL: define dso_local double @_Z19empty_double_struct14empty_double_s
-// CHECK-SAME: (double [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { i8, double } @_Z19empty_double_struct14empty_double_s
+// CHECK-SAME: (i8 [[TMP0:%.*]], double [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_double_s empty_double_struct(struct empty_double_s s) {
   return s;
 }
 
 struct double_empty_s {
   double f64;
   struct empty_s e;
 };
-// CHECK-LABEL: define dso_local double @_Z19double_empty_struct14double_empty_s
-// CHECK-SAME: (double [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { double, i8 } @_Z19double_empty_struct14double_empty_s
+// CHECK-SAME: (double [[TMP0:%.*]], i8 [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct double_empty_s double_empty_struct(struct double_empty_s s) {
   return s;
 }
 
 /// 2.c.ii. Others
 
 struct empty_float_char_s {
   struct empty_s e1;
   float f32;
   char c;
 };
-// CHECK-LABEL: define dso_local { float, i8 } @_Z23empty_float_char_struct18empty_float_char_s
-// CHECK-SAME: (float [[TMP0:%.*]], i8 [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local [2 x i64] @_Z23empty_float_char_struct18empty_float_char_s
+// CHECK-SAME: ([2 x i64] [[S_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_float_char_s empty_float_char_struct(struct empty_float_char_s s) {
   return s;
 }
 
 struct empty_float_double_s {
   struct empty_s e1;
   float f32;
   double f64;
 };
-// CHECK-LABEL: define dso_local { float, double } @_Z25empty_float_double_struct20empty_float_double_s
-// CHECK-SAME: (float [[TMP0:%.*]], double [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local [2 x i64] @_Z25empty_float_double_struct20empty_float_double_s
+// CHECK-SAME: ([2 x i64] [[S_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_float_double_s empty_float_double_struct(struct empty_float_double_s s) {
   return s;
 }
 
 /// 3 WOA > 2*GRLEN
 
 struct empty_long_empty_s {
   struct empty_s e1;
   long l;
   struct empty_s e2;
 };
 // CHECK-LABEL: define dso_local void @_Z23empty_long_empty_struct18empty_long_empty_s
 // CHECK-SAME: (ptr noalias sret([[STRUCT_EMPTY_LONG_EMPTY_S:%.*]]) align 8 [[AGG_RESULT:%.*]], ptr noundef [[S:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_long_empty_s empty_long_empty_struct(struct empty_long_empty_s s) {
   return s;
 }
 
 struct empty_double_empty_s {
   struct empty_s e1;
   double f64;
   struct empty_s e2;
 };
-// CHECK-LABEL: define dso_local double @_Z25empty_double_empty_struct20empty_double_empty_s
-// CHECK-SAME: (double [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local void @_Z25empty_double_empty_struct20empty_double_empty_s
+// CHECK-SAME: (ptr noalias sret([[STRUCT_EMPTY_DOUBLE_EMPTY_S:%.*]]) align 8 [[AGG_RESULT:%.*]], ptr noundef [[S:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_double_empty_s empty_double_empty_struct(struct empty_double_empty_s s) {
   return s;
 }