================
@@ -143,6 +143,10 @@ def CIR_RecordLayoutAttr : CIR_Attr<"RecordLayout",
"record_layout", [
- `record_align_in_bytes`: from `ASTRecordLayout::getAlignment()`.
Needed because CIR's DataLayout cannot account for
`__attribute__((aligned(N)))`.
+ - `is_empty`: whether the record carries no data for argument passing
----------------
erichkeane wrote:
Hmm... interesting. I still think this should be calculated off the layout,
but now wonder if we just need a second 'field' property. We have them marked
`padded`, but could we mark them
"effectively-padding-as-they-cant-really-hold-a-value" kinda thing?
Basically, the first example (with only unnamed bitfields) has a value that IS
entirely padding, its just user defined padding.
So either we could do better at marking 'padding' to include 'user padding' OR
have a separate flag for 'the user didn't give any field in this area a name,
so it is effectively padding'. I'm having trouble determining personally
whether those are DIFFERENT attributes of the type, or are effectively equal.
That is, will we ever do something 'different' based on:
"compiler-calculated-padding" vs "user-calculated-padding"?
>They are all AST facts the type does not preserve.
I don't know what you mean by `AST facts`, as the type itself is an `AST fact`.
BUT this is sort of my point. This is a particularly un-general attribute
that is based entirely on type/layout (vs the others you mention, which are
based on some parts of the type that we choose not to represent, at least for
the trivial dtor). BUT padding/fields/etc ARE.
https://github.com/llvm/llvm-project/pull/214742
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
