[PATCH] D30309: CodeGen: BlockPlacement: Precompute layout for chains of triangles.

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 27 14:27:06 PST 2017


On Mon, Feb 27, 2017 at 2:00 PM, Kyle Butt via Phabricator <
reviews at reviews.llvm.org> wrote:

> iteratee added a comment.
>
> In https://reviews.llvm.org/D30309#686772, @davidxl wrote:
>
> > 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.
>
>
> Well, long chains amortize the penalty, so looking for the shape is
> definitely necessary.
>
> I can adjust the static prediction if you'd like, but I have a source for
> the 60/40 stat:
>


The paper says the T/N ratio is about 2/1, which contradicts to your case
here.


There are more recent papers which looks at actual branch conditions:

 [1] "Branch Prediction for Free"        Ball and Larus; PLDI '93.
 [2] "Static Branch Frequency and Program Profile Analysis"      Wu and
Larus; MICRO-27.
 [3] "Corpus-based Static Branch Prediction"       Calder, Grunwald,
Lindsay, Martin, Mozer, and Zorn; PLDI '95.  */



> See page 13 here:
> http://digitalassets.lib.berkeley.edu/techreports/ucb/text/CSD-83-121.pdf
>
> 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.
>
>
Without path profile, how is it reasonable to make path correlation
assumptions?  In some cases, it is true some static analysis + static
heuristic can be developed to handle that.

However you made a valid point here. Before we have the machinery to
analysis/annotate/use such correlations, pattern matching may be the way to
go. However it is probably not a good idea to blindly look at the shapes.
Perhaps looking into conditions as well?  This also looks like more
suitable to be put into some utility.




> I really don't want to change this until I get a more specific feedback
> about what you'd like to see.
> Assuming a small amount of positive correlation (10%), the cutoff is 47%
> (including the frequency bonus) for a chain of 2 triangles that ends in a
> non-triangle,
> and 56% for a chain of triangles that ends in a triangle.
>
>
yes, if we can prove correlation, the longer the chain, the larger the
taken branch probability is allowed to enable tail-dup.



> Would you prefer that I adjust the static probabilities for triangles,


This is probably wrong to do (i.e, guess BP based on shape). I suspect the
benefit is mostly from the path correlation.



> and then run the comparisons against the thresholds I calculated above? I
> could even include the whole table from 2-10. (The threshold goes down as
> the # of triangles goes up)
>
>

Can you do some analysis on the benchmarks that benefit the long chain
duplication and study if it is possible to develop some simple heuristics
of path correlation?

David



>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D30309
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170227/50a1bb48/attachment.html>


More information about the llvm-commits mailing list