================
@@ -624,29 +624,42 @@ def CIR_VoidType : CIR_Type<"Void", "void"> {
//===----------------------------------------------------------------------===//
// RecordMemberKind
//
-// What a record member holds, for members that do not hold source data.
+// What a record member holds, and whether its extent is a declared one.
//===----------------------------------------------------------------------===//
def CIR_RecordMemberKind : CIR_I32EnumAttr<
"RecordMemberKind", "what a record member holds", [
I32EnumAttrCase<"Data", 0, "data">,
I32EnumAttrCase<"Pad", 1, "pad">,
- I32EnumAttrCase<"Empty", 2, "empty">
+ I32EnumAttrCase<"Empty", 2, "empty">,
----------------
adams381 wrote:
`empty` and `empty_bitfield` both say that the member holds nothing for
argument passing. However, `empty` marks a member the source sized and
`empty_bitfield` marks a member the compiler sized.
The two need separate marks because clang's x86-64 lowering asks two different
questions about an unnamed access unit and gets opposite answers. When
assigning eightbyte classes, `classify` skips the unit, under the comment
"Ignore padding bit-fields". When deciding whether an eightbyte's coerce type
can be narrowed, `BitsContainNoUserData` recurses on the field's declared type,
so the unit counts and the narrowing is blocked. `llvm::abi::FieldInfo`, in
the ABI library, already carries `IsBitField` and `IsUnnamedBitfield` for
exactly that split, and the marks are what let the bridge fill them in.
Without the marks the bridge's only control is whether the member appears in
the field list at all, which is one bit for two questions. This PR is prework
for pad-aware classification where we set those two flags from the marks, and
an unnamed unit then lowers to match classic.
https://github.com/llvm/llvm-project/pull/216864
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
