<div dir="ltr">Thanks for the fix, Benjamin!<div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">thanks,<br>Cong</div></div>
<br><div class="gmail_quote">On Sat, Sep 26, 2015 at 4:07 AM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@gmail.com" target="_blank">benny.kra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On 26.09.2015, at 09:13, İsmail Dönmez via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On Sat, Sep 26, 2015 at 2:09 AM, Cong Hou via llvm-commits<br>
> <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>> Author: conghou<br>
>> Date: Fri Sep 25 18:09:59 2015<br>
>> New Revision: 248633<br>
>><br>
>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=248633&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=248633&view=rev</a><br>
>> Log:<br>
>> Use fixed-point representation for BranchProbability.<br>
>><br>
>> BranchProbability now is represented by its numerator and denominator in uint32_t type. This patch changes this representation into a fixed point that is represented by the numerator in uint32_t type and a constant denominator 1<<31. This is quite similar to the representation of BlockMass in BlockFrequencyInfoImpl.h. There are several pros and cons of this change:<br>
>><br>
>> Pros:<br>
>><br>
>> 1. It uses only a half space of the current one.<br>
>> 2. Some operations are much faster like plus, subtraction, comparison, and scaling by an integer.<br>
>><br>
>> Cons:<br>
>><br>
>> 1. Constructing a probability using arbitrary numerator and denominator needs additional calculations.<br>
>> 2. It is a little less precise than before as we use a fixed denominator. For example, 1 - 1/3 may not be exactly identical to 1 / 3 (this will lead to many BranchProbability unit test failures). This should not matter when we only use it for branch probability. If we use it like a rational value for some precise calculations we may need another construct like ValueRatio.<br>
>><br>
>> One important reason for this change is that we propose to store branch probabilities instead of edge weights in MachineBasicBlock. We also want clients to use probability instead of weight when adding successors to a MBB. The current BranchProbability has more space which may be a concern.<br>
>><br>
>> Differential revision: <a href="http://reviews.llvm.org/D12603" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12603</a><br>
>><br>
>><br>
>> Modified:<br>
> [...]<br>
>>    llvm/trunk/test/Analysis/BranchProbabilityInfo/basic.ll<br>
>>    llvm/trunk/test/Analysis/BranchProbabilityInfo/loop.ll<br>
><br>
> These two tests fail with MSVC 2015 :<br>
><br>
> C:\cygwin64\home\ismail\src\llvm\test\Analysis\BranchProbabilityInfo\basic.ll:18:10:<br>
> error: expected string not found in input<br>
> ; CHECK: edge body -> exit probability is 0x04000000 / 0x80000000 = 3.12%<br>
>         ^<br>
> <stdin>:4:2: note: scanning from here<br>
> edge body -> exit probability is 0x04000000 / 0x80000000 = 3.13%<br>
> ^<br>
><br>
> C:\cygwin64\home\ismail\src\llvm\test\Analysis\BranchProbabilityInfo\loop.ll:27:10:<br>
> error: expected string not found in input<br>
> ; CHECK: edge do.body1 -> do.end probability is 0x04000000 / 0x80000000 = 3.12%<br>
>         ^<br>
> <stdin>:6:2: note: scanning from here<br>
> edge do.body1 -> do.end probability is 0x04000000 / 0x80000000 = 3.13%<br>
> ^<br>
<br>
</div></div>r248665 works around the different rounding behavior of printf on Windows.<br>
<br>
- Ben<br>
<br>
</blockquote></div><br></div>