[Mlir-commits] [mlir] [MLIR] Fix duplicated attribute nodes in MLIR bytecode deserialization (PR #151267)

[Tobias Gysi]

================
@@ -0,0 +1,32 @@
+// RUN: mlir-opt -emit-bytecode %s | mlir-translate --mlir-to-llvmir | FileCheck %s
+
+#di_basic_type = #llvm.di_basic_type<tag = DW_TAG_base_type, name = "int", sizeInBits = 32, encoding = DW_ATE_signed>
+#di_file = #llvm.di_file<"foo.c" in "/mlir/">
+#di_file1 = #llvm.di_file<"foo.c" in "/mlir/">
+#di_subprogram = #llvm.di_subprogram<recId = distinct[0]<>, isRecSelf = true>
+#di_compile_unit = #llvm.di_compile_unit<id = distinct[1]<>, sourceLanguage = DW_LANG_C11, file = #di_file, producer = "MLIR", isOptimized = true, emissionKind = Full, nameTableKind = None>
+#di_local_variable = #llvm.di_local_variable<scope = #di_subprogram, name = "a", file = #di_file1, line = 2, type = #di_basic_type>
+#di_subroutine_type = #llvm.di_subroutine_type<types = #di_basic_type>
+#di_subprogram1 = #llvm.di_subprogram<recId = distinct[0]<>, id = distinct[2]<>, compileUnit = #di_compile_unit, scope = #di_file1, name = "main", file = #di_file1, line = 1, scopeLine = 1, subprogramFlags = "Definition|Optimized", type = #di_subroutine_type, retainedNodes = #di_local_variable>
+#di_local_variable1 = #llvm.di_local_variable<scope = #di_subprogram1, name = "a", file = #di_file1, line = 2, type = #di_basic_type>
+
+module attributes {dlti.dl_spec = #dlti.dl_spec<i64 = dense<64> : vector<2xi64>, !llvm.ptr = dense<64> : vector<4xi64>>, llvm.ident = "MLIR", llvm.target_triple = "x86_64-unknown-linux-gnu"} {
----------------
gysit wrote:

Trying to understand but I am not fully there yet.

So the IR above seems not correct since there should always be a "normal" subprogram before the self recursive reference when walking from the location down the attribute tree.

However, it seems more like the distinct attribute is the issue here? They are indeed special in the sense that creating a distinct attribute every time produces a new attribute. In the reproducer there is only one of them though, which again makes me wonder if this can be the problem. 



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