<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 11:29 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Sorry I haven't responded earlier, but one point here still doesn't make sense to me:</div><span class=""><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 10:27 AM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">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"><div style="overflow:hidden">Diego and I have discussed this according to the feedback received. We<br>
have revised plan for this (see Diego's last reply).  Here is a more<br>
detailed re-cap:<br>
<br>
1) keep MD_prof definition as it is today; also keep using the<br>
frequency propagation as it is (assuming programs with irreducible<br>
loops are not common and not important. If it turns out to be<br>
otherwise, we will revisit this).<br>
2) fix all problems that lead to wrong 'frequency/count' computed from<br>
the frequency propagation algorithm<br>
   2.1) relax 32bit limit</div></blockquote></div><br></div></span><div class="gmail_extra">I still don't understand why this is important or useful.... Maybe I'm just missing something.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Given the current meaning of MD_prof, it seems like the result of limiting this to 32-bits is that the maximum relative ratio of probabilities between two successors of a basic block with N successors is (2 billion / N):1 -- what is the circumstance that makes this resolution insufficient?</div><div class="gmail_extra"><br></div><div class="gmail_extra">It also doesn't seem *bad* per-se, I just don't see what it improves, and it does cost memory...</div></div></blockquote><div><br></div><div>right -- there is some ambiguity here -- it is needed if we were to change MD_prof's definition to represent branch count.  However, with the new plan, the removal of the limit only applies to the function entry count representation planned. </div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>