1 ; RUN: llvm-as <%s -bitcode-mdindex-threshold=0 | llvm-bcanalyzer -dump | FileCheck %s 2 ; Check that distinct nodes break uniquing cycles, so that uniqued subgraphs 3 ; are always in post-order. 4 ; 5 ; It may not be immediately obvious why this is an interesting graph. There 6 ; are three nodes in a cycle, and one of them (!1) is distinct. Because the 7 ; entry point is !2, a naive post-order traversal would give !3, !1, !2; but 8 ; this means when !3 is parsed the reader will need a forward reference for !2. 9 ; Forward references for uniqued node operands are expensive, whereas they're 10 ; cheap for distinct node operands. If the distinct node is emitted first, the 11 ; uniqued nodes don't need any forward references at all. 12 13 ; Nodes in this testcase are numbered to match how they are referenced in 14 ; bitcode. !3 is referenced as opN=3. 15 16 ; CHECK: <DISTINCT_NODE op0=3/> 17 !1 = distinct !{!3} 18 19 ; CHECK-NEXT: <NODE op0=1/> 20 !2 = !{!1} 21 22 ; CHECK-NEXT: <NODE op0=2/> 23 !3 = !{!2} 24 25 ; Before the named records we emit the index containing the position of the 26 ; previously emitted records 27 ; CHECK-NEXT: <INDEX {{.*}} (offset match) 28 29 ; Note: named metadata nodes are not cannot reference null so their operands 30 ; are numbered off-by-one. 31 ; CHECK-NEXT: <NAME 32 ; CHECK-NEXT: <NAMED_NODE op0=1/> 33 !named = !{!2} 34
