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