<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 24, 2015 at 3:44 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank" class="cremed">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Apr 24, 2015 at 12:29 PM, Diego Novillo <<a href="mailto:dnovillo@google.com" target="_blank" class="cremed">dnovillo@google.com</a>> wrote:<br>
><br>
><br>
> On Fri, Apr 24, 2015 at 3:28 PM, Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank" class="cremed">davidxl@google.com</a>><br>
> wrote:<br>
>><br>
>> yes -- for count representation, 64 bit is needed. The branch weight<br>
>> here is different and does not needs to be 64bit to represent branch<br>
>> probability precisely.<br>
><br>
><br>
> Actually, the branch weights are really counts.<br>
<br>
</span>No -- I think that is our original proposal (including changing the<br>
meaning of MD_prof meta data) :).</blockquote><div><br></div><div>Sure.  Though they kind of are. They get massaged and smoothed when branch_weights are placed from the raw counts, but for sufficiently small values they are very close to counts.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
>They get converted to<br>
> frequencies.  For frequencies, we don't really need 64bits, as they're just<br>
> comparative values that can be squished into 32bits.  It's the branch<br>
> weights being 32 bit quantities that are throwing off the calculations.<br>
<br>
</span>Do you still see the issue after fixing bhe bug (limit without scaling) in<br>
 BranchProbabilityInfo::calcMetadataWeights ?<br></blockquote><div><br></div><div>That's the fix I was contemplating initially. I was curious at whether moving to 64bit would make this easier.</div><div><br></div><div><br></div><div>Diego.</div></div></div></div>