1; RUN: llvm-as <%s | llvm-bcanalyzer -dump | FileCheck %s
2; Check that nodes are emitted in post-order to minimize the need for temporary
3; nodes.  The graph structure is designed to foil naive implementations of
4; iteratitive post-order traersals: the leaves, !3 and !4, are reachable from
5; the entry node, !6, as well as from !5.  There is one leaf on either side to
6; be sure it tickles bugs whether operands are visited forward or reverse.
7
8; Nodes in this testcase are numbered to match how they are referenced in
9; bitcode.  !3 is referenced as opN=3.
10
11; We don't care about the order of the strings (or of !3 and !4).  Let's just
12; make sure the strings are first and make it clear that there are two of them.
13; CHECK:       <STRINGS {{.*}} num-strings = 2 {
14; CHECK-NEXT:    'leaf
15; CHECK-NEXT:    'leaf
16; CHECK-NEXT:  }
17
18; The leafs should come first (in either order).
19; CHECK-NEXT:  <NODE op0=1/>
20; CHECK-NEXT:  <NODE op0=2/>
21!3 = !{!"leaf3"}
22!4 = !{!"leaf4"}
23
24; CHECK-NEXT:  <NODE op0=3 op1=4/>
25!5 = !{!3, !4}
26
27; CHECK-NEXT:  <NODE op0=3 op1=5 op2=4/>
28!6 = !{!3, !5, !4}
29
30; Note: named metadata nodes are not cannot reference null so their operands
31; are numbered off-by-one.
32; CHECK-NEXT:  <NAME
33; CHECK-NEXT:  <NAMED_NODE op0=5/>
34!named = !{!6}
35