<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 1, 2017 at 12:23 PM, Chandler Carruth via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">chandlerc added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D30309#687816" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D30309#687816</a>, @iteratee wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D30309#686772" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D30309#686772</a>, @davidxl wrote:<br>
><br>
> > if BP is not correct,  it is better to improve static branch prediction.  We explicitly added a threshold for the cost based analysis result to kick in just to be conservative when the branch probability is not biased enough.    Even for the long chain case, tail dup is enabled for 50/50 case, but the real profile is 40/60, taildup will hurt performance. I don't see the reason to by pass the branch prob + cost analysis by just looking at the shape.<br>
><br>
><br>
> Well, long chains amortize the penalty, so looking for the shape is definitely necessary.<br>
><br>
> I can adjust the static prediction if you'd like, but I have a source for the 60/40 stat:<br>
</span><span class="">>  See page 13 here:<br>
>  <a href="http://digitalassets.lib.berkeley.edu/techreports/ucb/text/CSD-83-121.pdf" rel="noreferrer" target="_blank">http://digitalassets.lib.<wbr>berkeley.edu/techreports/ucb/<wbr>text/CSD-83-121.pdf</a><br>
<br>
<br>
</span>FWIW, I remember discussing this a loooooong time ago as we were really starting to set up static prediction. At the time, there was some desire to not try to put this weak of signal into static predictions. They have ways of compounding and ending up producing pretty weird results. So I'm not really sure the probabilities we use in static prediction are wrong. (Or rather, are wrong by enough of a margin or in enough cases to be worth shifting.) Maybe we should revisit this, but I'm always a bit skeptical of static heuristics with this small of a difference...<br>
<span class=""><br>
> The chains also allow us to make a correlation assumption. I can explicitly calculate that as well, however, edge frequencies run into aliasing problems. It seems that BlockFrequency wasn't designed to allow for calculations like these.<br>
<br>
</span>Based on your explanation to me about how all of this works, my understanding is this:<br>
<br>
Branches in these kinds of long chains of triangles empirically correlate, even though they may individually have something like 50/50 probability. And the advantage of *correlation* is pretty specific to the *layout* we're doing here.<br>
<br>
Given that, I think it is very reasonable to handle this within the layout code by detecting the pattern of CFG combined with (nearly) 50/50 probabilities, and choosing to prioritize a layout this is profitable in the face of correlation because we believe that such correlation will often occur.<br>
<br>
Anyways, just my two cents. I'll leave figuring out the end state to you and David. =D<br></blockquote><div><br></div><div><br></div><div>Yes -- I agree, see my previous response about this -- block layout is the place to detect and consume such info for now.  What I asked Kyle is to collect some empirical data/examples to increase the confidence.  For instance, using examples to show how the long triangle changes usually look like and why there is high confidence the correlation exists (also not the reverse correlation which will be bad).</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">
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D30309" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D30309</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>