[Mlir-commits] [mlir] [MLIR][LLVM] Support Recursive DITypes (PR #80251)

[Tobias Gysi]

================
@@ -289,7 +316,19 @@ DINodeAttr DebugImporter::translate(llvm::DINode *node) {
     return nullptr;
   };
   if (DINodeAttr attr = translateNode(node)) {
-    nodeToAttr.insert({node, attr});
+    // If this node was marked as recursive, set its recId.
+    if (auto recType = dyn_cast<DIRecursiveTypeAttrInterface>(attr)) {
+      if (DistinctAttr recId = translationStack.lookup(node)) {
+        attr = cast<DINodeAttr>(recType.withRecId(recId));
+        // Remove the unbound recursive ID from the set of unbound self
+        // references in the translation stack.
+        unboundRecursiveSelfRefs.back().erase(recId);
+      }
+    }
+
+    // Only cache fully self-contained nodes.
+    if (unboundRecursiveSelfRefs.back().empty())
----------------
gysit wrote:

@zyx-billy the import now works on all our tests but we found a efficiency issue. One of our test files grows by roughly factor 10x when importing and I see may versions of the same unbounded version of a composite type. I suspect this is the case nested recursive types. Then the same DICompositeType may be translated several times with different distinct identifiers since only once we left the outermost cycle we actually cache the type.

The solution to this seems not so trivial since caching a composite type is only really possible once we know there is no unbound type. Could we maybe have some sort of temporary cache during the traversal that keeps track of translated recursive types given a set of currently open unbounded references. That could possibly handle the case where in a cycle there are several entry nodes into a nested cycle...

Didn't have time to think about this in depth yet but you may have had thoughts when implementing this.

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