test/Analysis/BlockFrequencyInfo/irreducible.ll

   1 ; RUN: opt < %s -analyze -block-freq | FileCheck %s
   2
   3 ; A loop with multiple exits should be handled correctly.
   4 ;
   5 ; CHECK-LABEL: Printing analysis {{.*}} for function 'multiexit':
   6 ; CHECK-NEXT: block-frequency-info: multiexit
   7 define void @multiexit(i1 %x) {
   8 ; CHECK-NEXT: entry: float = 1.0, int = [[ENTRY:[0-9]+]]
   9 entry:
  10   br label %loop.1
  11
  12 ; CHECK-NEXT: loop.1: float = 1.333{{3*}},
  13 loop.1:
  14   br i1 %x, label %exit.1, label %loop.2, !prof !0
  15
  16 ; CHECK-NEXT: loop.2: float = 0.666{{6*7}},
  17 loop.2:
  18   br i1 %x, label %exit.2, label %loop.1, !prof !1
  19
  20 ; CHECK-NEXT: exit.1: float = 0.666{{6*7}},
  21 exit.1:
  22   br label %return
  23
  24 ; CHECK-NEXT: exit.2: float = 0.333{{3*}},
  25 exit.2:
  26   br label %return
  27
  28 ; CHECK-NEXT: return: float = 1.0, int = [[ENTRY]]
  29 return:
  30   ret void
  31 }
  32
  33 !0 = metadata !{metadata !"branch_weights", i32 3, i32 3}
  34 !1 = metadata !{metadata !"branch_weights", i32 5, i32 5}
  35
  36 ; The current BlockFrequencyInfo algorithm doesn't handle multiple entrances
  37 ; into a loop very well.  The frequencies assigned to blocks in the loop are
  38 ; predictable (and not absurd), but also not correct and therefore not worth
  39 ; testing.
  40 ;
  41 ; There are two testcases below.
  42 ;
  43 ; For each testcase, I use a CHECK-NEXT/NOT combo like an XFAIL with the
  44 ; granularity of a single check.  If/when this behaviour is fixed, we'll know
  45 ; about it, and the test should be updated.
  46 ;
  47 ; Testcase #1
  48 ; ===========
  49 ;
  50 ; In this case c1 and c2 should have frequencies of 15/7 and 13/7,
  51 ; respectively.  To calculate this, consider assigning 1.0 to entry, and
  52 ; distributing frequency iteratively (to infinity).  At the first iteration,
  53 ; entry gives 3/4 to c1 and 1/4 to c2.  At every step after, c1 and c2 give 3/4
  54 ; of what they have to each other.  Somehow, all of it comes out to exit.
  55 ;
  56 ;       c1 = 3/4 + 1/4*3/4 + 3/4*3^2/4^2 + 1/4*3^3/4^3 + 3/4*3^3/4^3 + ...
  57 ;       c2 = 1/4 + 3/4*3/4 + 1/4*3^2/4^2 + 3/4*3^3/4^3 + 1/4*3^3/4^3 + ...
  58 ;
  59 ; Simplify by splitting up the odd and even terms of the series and taking out
  60 ; factors so that the infite series matches:
  61 ;
  62 ;       c1 =  3/4 *(9^0/16^0 + 9^1/16^1 + 9^2/16^2 + ...)
  63 ;          +  3/16*(9^0/16^0 + 9^1/16^1 + 9^2/16^2 + ...)
  64 ;       c2 =  1/4 *(9^0/16^0 + 9^1/16^1 + 9^2/16^2 + ...)
  65 ;          +  9/16*(9^0/16^0 + 9^1/16^1 + 9^2/16^2 + ...)
  66 ;
  67 ;       c1 = 15/16*(9^0/16^0 + 9^1/16^1 + 9^2/16^2 + ...)
  68 ;       c2 = 13/16*(9^0/16^0 + 9^1/16^1 + 9^2/16^2 + ...)
  69 ;
  70 ; Since this geometric series sums to 16/7:
  71 ;
  72 ;       c1 = 15/7
  73 ;       c2 = 13/7
  74 ;
  75 ; If we treat c1 and c2 as members of the same loop, the exit frequency of the
  76 ; loop as a whole is 1/4, so the loop scale should be 4.  Summing c1 and c2
  77 ; gives 28/7, or 4.0, which is nice confirmation of the math above.
  78 ;
  79 ; However, assuming c1 precedes c2 in reverse post-order, the current algorithm
  80 ; returns 3/4 and 13/16, respectively.  LoopInfo ignores edges between loops
  81 ; (and doesn't see any loops here at all), and -block-freq ignores the
  82 ; irreducible edge from c2 to c1.
  83 ;
  84 ; CHECK-LABEL: Printing analysis {{.*}} for function 'multientry':
  85 ; CHECK-NEXT: block-frequency-info: multientry
  86 define void @multientry(i1 %x) {
  87 ; CHECK-NEXT: entry: float = 1.0, int = [[ENTRY:[0-9]+]]
  88 entry:
  89   br i1 %x, label %c1, label %c2, !prof !2
  90
  91 ; This is like a single-line XFAIL (see above).
  92 ; CHECK-NEXT: c1:
  93 ; CHECK-NOT: float = 2.142857{{[0-9]*}},
  94 c1:
  95   br i1 %x, label %c2, label %exit, !prof !2
  96
  97 ; This is like a single-line XFAIL (see above).
  98 ; CHECK-NEXT: c2:
  99 ; CHECK-NOT: float = 1.857142{{[0-9]*}},
 100 c2:
 101   br i1 %x, label %c1, label %exit, !prof !2
 102
 103 ; We still shouldn't lose any frequency.
 104 ; CHECK-NEXT: exit: float = 1.0, int = [[ENTRY]]
 105 exit:
 106   ret void
 107 }
 108
 109 ; Testcase #2
 110 ; ===========
 111 ;
 112 ; In this case c1 and c2 should be treated as equals in a single loop.  The
 113 ; exit frequency is 1/3, so the scaling factor for the loop should be 3.0.  The
 114 ; loop is entered 2/3 of the time, and c1 and c2 split the total loop frequency
 115 ; evenly (1/2), so they should each have frequencies of 1.0 (3.0*2/3*1/2).
 116 ; Another way of computing this result is by assigning 1.0 to entry and showing
 117 ; that c1 and c2 should accumulate frequencies of:
 118 ;
 119 ;       1/3   +   2/9   +   4/27  +   8/81  + ...
 120 ;     2^0/3^1 + 2^1/3^2 + 2^2/3^3 + 2^3/3^4 + ...
 121 ;
 122 ; At the first step, c1 and c2 each get 1/3 of the entry.  At each subsequent
 123 ; step, c1 and c2 each get 1/3 of what's left in c1 and c2 combined.  This
 124 ; infinite series sums to 1.
 125 ;
 126 ; However, assuming c1 precedes c2 in reverse post-order, the current algorithm
 127 ; returns 1/2 and 3/4, respectively.  LoopInfo ignores edges between loops (and
 128 ; treats c1 and c2 as self-loops only), and -block-freq ignores the irreducible
 129 ; edge from c2 to c1.
 130 ;
 131 ; Below I use a CHECK-NEXT/NOT combo like an XFAIL with the granularity of a
 132 ; single check.  If/when this behaviour is fixed, we'll know about it, and the
 133 ; test should be updated.
 134 ;
 135 ; CHECK-LABEL: Printing analysis {{.*}} for function 'crossloops':
 136 ; CHECK-NEXT: block-frequency-info: crossloops
 137 define void @crossloops(i2 %x) {
 138 ; CHECK-NEXT: entry: float = 1.0, int = [[ENTRY:[0-9]+]]
 139 entry:
 140   switch i2 %x, label %exit [ i2 1, label %c1
 141                               i2 2, label %c2 ], !prof !3
 142
 143 ; This is like a single-line XFAIL (see above).
 144 ; CHECK-NEXT: c1:
 145 ; CHECK-NOT: float = 1.0,
 146 c1:
 147   switch i2 %x, label %exit [ i2 1, label %c1
 148                               i2 2, label %c2 ], !prof !3
 149
 150 ; This is like a single-line XFAIL (see above).
 151 ; CHECK-NEXT: c2:
 152 ; CHECK-NOT: float = 1.0,
 153 c2:
 154   switch i2 %x, label %exit [ i2 1, label %c1
 155                               i2 2, label %c2 ], !prof !3
 156
 157 ; We still shouldn't lose any frequency.
 158 ; CHECK-NEXT: exit: float = 1.0, int = [[ENTRY]]
 159 exit:
 160   ret void
 161 }
 162
 163 !2 = metadata !{metadata !"branch_weights", i32 3, i32 1}
 164 !3 = metadata !{metadata !"branch_weights", i32 2, i32 2, i32 2}
 165
 166 ; A reducible loop with irreducible control flow inside should still have
 167 ; correct exit frequency.
 168 ;
 169 ; CHECK-LABEL: Printing analysis {{.*}} for function 'loop_around_irreducible':
 170 ; CHECK-NEXT: block-frequency-info: loop_around_irreducible
 171 define void @loop_around_irreducible(i1 %x) {
 172 ; CHECK-NEXT: entry: float = 1.0, int = [[ENTRY:[0-9]+]]
 173 entry:
 174   br label %loop
 175
 176 ; CHECK-NEXT: loop: float = [[HEAD:[0-9.]+]], int = [[HEADINT:[0-9]+]]
 177 loop:
 178   br i1 %x, label %left, label %right
 179
 180 ; CHECK-NEXT: left:
 181 left:
 182   br i1 %x, label %right, label %loop.end
 183
 184 ; CHECK-NEXT: right:
 185 right:
 186   br i1 %x, label %left, label %loop.end
 187
 188 ; CHECK-NEXT: loop.end: float = [[HEAD]], int = [[HEADINT]]
 189 loop.end:
 190   br i1 %x, label %loop, label %exit
 191
 192 ; CHECK-NEXT: float = 1.0, int = [[ENTRY]]
 193 exit:
 194   ret void
 195 }