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

[Kyle Butt via Phabricator via llvm-commits]

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:
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.

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.

Would you prefer that I adjust the static probabilities for triangles, 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)


Repository:
  rL LLVM

https://reviews.llvm.org/D30309