<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 8, 2015 at 9:39 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> On 2015-Sep-05, at 22:41, David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br>
><br>
><br>
> ================<br>
> Comment at: test/Analysis/BlockFrequencyInfo/basic.ll:71<br>
> @@ -70,3 +70,3 @@<br>
> ; The 'case_c' branch is predicted more likely via branch weight metadata.<br>
> -; CHECK-NEXT: case_c: float = 0.8,<br>
> +; CHECK-NEXT: case_c: float = 0.8<br>
> case_c:<br>
> ----------------<br>
> where does the coma come from?<br>
<br>
</span>The comma was there to confirm that we get *exactly* 0.8.  Why has<br>
that changed?<br></blockquote><div><br></div><div>With fixed point representation, we won't get exactly 0.8 here but 0.8000000001. Should I restrict the output precision when printing this value, or use regex or exact 0.8000000001 in the test case?</div><div><br></div><div><br></div><div>Cong</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
(I'm behind on this review; maybe the answer is obvious from the patch,<br>
but it seems suspicious.  I'll try to get to this today or tomorrow.)<br>
<br>
><br>
><br>
> <a href="http://reviews.llvm.org/D12603" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12603</a><br>
><br>
><br>
><br>
<br>
</blockquote></div><br></div></div>