================
@@ -229,4 +229,32 @@ def ConstPtrAttr : CIR_Attr<"ConstPtr", "ptr",
[TypedAttrInterface]> {
}];
}
+//===----------------------------------------------------------------------===//
+// RecordLayoutAttr
+//===----------------------------------------------------------------------===//
+
+// Used to decouple layout information from the record type. RecordType's
+// uses this attribute to cache that information.
+
+def RecordLayoutAttr : CIR_Attr<"RecordLayout", "record_layout"> {
+ let summary = "ABI specific information about a record layout";
+ let description = [{
+ Holds layout information often queried by !cir.record users
+ during lowering passes and optimizations.
+ }];
+
+ let parameters = (ins "unsigned":$size,
+ "unsigned":$alignment,
+ "bool":$padded,
+ "mlir::Type":$largest_member,
----------------
bcardosolopes wrote:
`RecordLayoutAttr` is computed lazily, and the idea is that whenever we have to
walk the elements we then compute all properties, because they all require a
single pass. You might be right that it's probably not too bad for
`largest_member` to be done every time this query is needed, but (a) I haven't
seen measurements indicating either way (and would pick the compile time
defensive approach) and (b) `largest_member` makes sense along side the other
properties computed here IMO.
> which for some reason diverges from CodeGen
Because we have slightly higher level unions than MLIR, this is the price to be
paid. FWIW, @gitoleg has done a lot of work to make unions work, including
often running csmith and fixing correctness issues.
https://github.com/llvm/llvm-project/pull/136036
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
