[Mlir-commits] [mlir] [mlir] Add support for recursive elements in DICompositeTypeAttr. (PR #74948)

[Tobias Gysi]

================
@@ -684,6 +663,61 @@ def LLVM_AliasScopeDomainAttr : LLVM_Attr<"AliasScopeDomain",
   let assemblyFormat = "`<` struct(params) `>`";
 }
 
+//===----------------------------------------------------------------------===//
+// DICompositeTypeAttr
+//===----------------------------------------------------------------------===//
+
+def LLVM_DICompositeTypeAttr : LLVM_Attr<"DICompositeType", "di_composite_type",
+                                         /*traits=*/[NativeTypeTrait<"IsMutable">], "DITypeAttr"> {
+  let parameters = (ins
+    OptionalParameter<"unsigned">:$tag,
+    OptionalParameter<"StringAttr">:$name,
+    OptionalParameter<"DIFileAttr">:$file,
+    OptionalParameter<"uint32_t">:$line,
+    OptionalParameter<"DIScopeAttr">:$scope,
+    OptionalParameter<"DITypeAttr">:$baseType,
+    OptionalParameter<"DIFlags", "DIFlags::Zero">:$flags,
+    OptionalParameter<"uint64_t">:$sizeInBits,
+    OptionalParameter<"uint64_t">:$alignInBits,
+    OptionalArrayRefParameter<"DINodeAttr">:$elements,
+    OptionalParameter<"DistinctAttr">:$identifier
----------------
gysit wrote:

I would consider putting all the non-mutable fields (so probably everything except for the id and the elements) into a separate helper attribute that can be defined in tablegen. That way there printing an parsing code gets much simpler and we can more easily make parameters optional or mandatory and add new fields if necessary.

The new attribute could be called LLVM_DICompositeTypeInfoAttr or similar and it should not derive from any base class. Additionally, it probably makes sense to make sure it prints using an alias to make the DICompositType definitions a bit shorter.

I know that such attribute composition is not super nice either. However, I believe I prefer the slight inconveniences when using the attribute (for most compiler passes this is a route through thing anyways) over long and error prone printer and parser methods. Especially since I assume we may add new parameters here and make some of them non-optional etc.

https://github.com/llvm/llvm-project/pull/74948