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.
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.
13 ; Nodes in this testcase are numbered to match how they are referenced in
14 ; bitcode. !3 is referenced as opN=3.
16 ; CHECK: <DISTINCT_NODE op0=3/>
19 ; CHECK-NEXT: <NODE op0=1/>
22 ; CHECK-NEXT: <NODE op0=2/>
25 ; Before the named records we emit the index containing the position of the
26 ; previously emitted records
27 ; CHECK-NEXT: <INDEX {{.*}} (offset match)
29 ; Note: named metadata nodes are not cannot reference null so their operands
30 ; are numbered off-by-one.
32 ; CHECK-NEXT: <NAMED_NODE op0=1/>