blob: 0cebcbd1d7d45f409c7d7b89e29c8759456a238b [file] [log] [blame]
Mehdi Amini89bf9692016-12-28 22:30:28 +00001; RUN: llvm-as <%s -bitcode-mdindex-threshold=0 | llvm-bcanalyzer -dump | FileCheck %s
Duncan P. N. Exon Smith29fa04d2016-04-23 04:59:22 +00002; 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
Mehdi Amini89bf9692016-12-28 22:30:28 +000025; Before the named records we emit the index containing the position of the
26; previously emitted records
27; CHECK-NEXT: <INDEX {{.*}} (offset match)
28
Duncan P. N. Exon Smith29fa04d2016-04-23 04:59:22 +000029; 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}