<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 28, 2015 at 8:49 AM, Kevin B. Smith via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">kbsmith1 added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D12341#235124" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12341#235124</a>, @kparzysz wrote:<br>
<br>
> In <a href="http://reviews.llvm.org/D12341#234593" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12341#234593</a>, @kbsmith1 wrote:<br>
><br>
</span><span class="">> > I am suggesting that you only have a single number that represents the percentage of time that the direction is mispredicted.<br>
><br>
><br>
</span><span class="">> This is really the original idea if we assume that a change of direction causes a misprediction.  The problem with tracking "misprediction" rate is that it does depend on the specific hardware.  The implementation of the hardware branch prediction may change between subtargets of the same target, which is why I proposed tracking the behavior of the branch instead.  A subtarget could then use this information to estimate the misprediction rate, which may not be as accurate as tracking misprediction itself for that subtarget, but it would be portable.<br>
<br>
<br>
</span>The assumption that a change in branch direction causes a misprediction is just not a correct assumption.  Further most branch predictors have global state such that they are affected by other nearby branches, and also other branches that precede them in execution order. Compiler's really cannot model this, and thus attempting to discern/compute branch predictability from a pattern based on a specific implementation is unlikely to be successful. </blockquote><div><br></div><div>Absolutely; at this point, trying to do anything fine-grained with concrete knowledge of branch prediction probabilities is still a research problem AFAIK. It's premature abstraction to try to generalize what Sanjay is doing in this patch, which has a clear use case: the user is an oracle telling the optimizer that the usual assumptions about the effectiveness of branch prediction should not be made.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And most branch prediction algorithms are patented or closely guarded intellectual property.  Having an implementation of various HW algorithms seems unlikely to be coded into LLVM. A boolean serves the immediate need, but I think a 0 to 100 integer, with 0 meaning completely predictable and 100 meaning completely unpredictable can serve that same purpose, while also allowing HW feedback.  In actual practice, I'd expect anything with a unpredictability value higher than about 10 would be considered pretty unpredictable.  HW branch prediction rates (correct predictions/total branches, over all branches in a program) often run in the 95-98% range, making any branch with more than 10% unpredictability, less predictable than an average branch.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D12341" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12341</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>