test/Bitcode/mdnodes-in-post-order.ll

   1 ; RUN: llvm-as <%s -bitcode-mdindex-threshold=0 | 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 ; Before the records we emit an offset to the index for the block
  19 ; CHECK-NEXT:   <INDEX_OFFSET
  20
  21 ; The leafs should come first (in either order).
  22 ; CHECK-NEXT:  <NODE op0=1/>
  23 ; CHECK-NEXT:  <NODE op0=2/>
  24 !3 = !{!"leaf3"}
  25 !4 = !{!"leaf4"}
  26
  27 ; CHECK-NEXT:  <NODE op0=3 op1=4/>
  28 !5 = !{!3, !4}
  29
  30 ; CHECK-NEXT:  <NODE op0=3 op1=5 op2=4/>
  31 !6 = !{!3, !5, !4}
  32
  33 ; Before the named records we emit the index containing the position of the
  34 ; previously emitted records
  35 ; CHECK-NEXT:   <INDEX {{.*}} (offset match)
  36
  37 ; Note: named metadata nodes are not cannot reference null so their operands
  38 ; are numbered off-by-one.
  39 ; CHECK-NEXT:  <NAME
  40 ; CHECK-NEXT:  <NAMED_NODE op0=5/>
  41 !named = !{!6}