File: mdnodes-distinct-nodes-break-cycles.ll

package info (click to toggle)
llvm-toolchain-9 1%3A9.0.1-16
  • links: PTS, VCS
  • area: main
  • in suites: bullseye
  • size: 882,436 kB
  • sloc: cpp: 4,167,636; ansic: 714,256; asm: 457,610; python: 155,927; objc: 65,094; sh: 42,856; lisp: 26,908; perl: 7,786; pascal: 7,722; makefile: 6,881; ml: 5,581; awk: 3,648; cs: 2,027; xml: 888; javascript: 381; ruby: 156
file content (33 lines) | stat: -rw-r--r-- 1,303 bytes parent folder | download | duplicates (28)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
; RUN: llvm-as <%s -bitcode-mdindex-threshold=0 | llvm-bcanalyzer -dump | FileCheck %s
; Check that distinct nodes break uniquing cycles, so that uniqued subgraphs
; are always in post-order.
;
; It may not be immediately obvious why this is an interesting graph.  There
; are three nodes in a cycle, and one of them (!1) is distinct.  Because the
; entry point is !2, a naive post-order traversal would give !3, !1, !2; but
; this means when !3 is parsed the reader will need a forward reference for !2.
; Forward references for uniqued node operands are expensive, whereas they're
; cheap for distinct node operands.  If the distinct node is emitted first, the
; uniqued nodes don't need any forward references at all.

; Nodes in this testcase are numbered to match how they are referenced in
; bitcode.  !3 is referenced as opN=3.

; CHECK:       <DISTINCT_NODE op0=3/>
!1 = distinct !{!3}

; CHECK-NEXT:  <NODE op0=1/>
!2 = !{!1}

; CHECK-NEXT:  <NODE op0=2/>
!3 = !{!2}

; Before the named records we emit the index containing the position of the
; previously emitted records
; CHECK-NEXT:   <INDEX {{.*}} (offset match)

; Note: named metadata nodes are not cannot reference null so their operands
; are numbered off-by-one.
; CHECK-NEXT:  <NAME
; CHECK-NEXT:  <NAMED_NODE op0=1/>
!named = !{!2}