<div class="gmail_quote">After some discussion on IRC...</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Sun, Oct 23, 2011 at 4:19 AM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@googlemail.com">benny.kra@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">+  int64_t compare(BranchProbability RHS) const {<br>
+    return (uint64_t)N * RHS.D - (uint64_t)D * RHS.N;<br>
+  }<br></blockquote><div><br></div><div>It would be good to comment here that the result of the LHS of the subtract can't be larger than INT64_MAX without the RHS being large enough to reduce it because N <= D. It might also be nice to just assert that fact.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">--- llvm/trunk/unittests/Support/BlockFrequencyTest.cpp (original)<br>
+++ llvm/trunk/unittests/Support/BlockFrequencyTest.cpp Sun Oct 23 06:19:14 2011<br>
@@ -53,4 +53,24 @@<br>
   EXPECT_EQ(Freq.getFrequency(), UINT64_MAX);<br>
 }<br>
<br>
+TEST(BlockFrequencyTest, ProbabilityCompare) {<br>
+  BranchProbability A(4, 5);<br>
+  BranchProbability B(4U << 29, 5U << 29);<br></blockquote><div><br></div><div>Maybe add a test case that compares B against a RHS with a similarly large denominator value to ensure that overflow of INT64_MAX is indeed brought back down in the computation? In particular the interesting one to my mind is (UINT32_MAX, UINT32_MAX) vs. (1, UINT32_MAX).</div>
</div>