[clang] [CIR] Handle an empty C++ class in x86_64 callconv lowering (PR #214742)

[Erich Keane via cfe-commits]

================
@@ -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